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A.  I PARALLKL  BUS  ARCIUTKCTURK  DKSCRIPTION 


A.  LI  General 

This  section  describes  a parallel  non-dedicatod  bus  architecture.  The  bus  chosen  n.’semblus  the  PDP-11 
Dnibus*  in  that  it  is  a subset  of  it.  There  is  a hierarchy  of  control  defined  within  this  architecture. 

The  first  level  in  this  hierarchy  is  the  control  mechanism  for  data  transfer  on  the  bus,  which  is  specified 
in  great  detail  in  the  remaining  section.  In  general  terms,  the  modules  act  in  master-slave  states  during  a 
data  transfer.  All  data  transfers  within  the  bus  are  fully  interlocked  non-synchronous  types.  The  inter- 
locked non-synchronous  facility  provides  compatibility  between  slow  and  fast  acrcess  modules.  Electrical 
daisy  chaining  between  the  bus  acquisition  logic  of  the  Bus  Exchange  Units  (BEU)  resolves  contention. 
The  general  nature  of  this  type  of  transfer  facility  allows  for  one  module  to  crontinue  to  hold  the  bus 
indefinitely.  To  prevent  this  from  being  a problem,  single  word  transfers  should  be  u.sed  by  the  modules. 
No  penally  in  bus  bandwidth  is  paid  because  the  bus  acquisition  sequence  has  two  states  “next  ma.ster’’ 
and  “current  master”.  By  placing  the  limit  of  single  word  transfers  on  the  modules  the  highest  priority 
modules  is  guaranteed  50%  of  the  available  bus  transfers.  A hazard  still  exists  when  using  slow  access 
modules  on  the  bus.  Analysis  must  be  performed  to  insure  that  the  bus  is  nut  held  by  any  module  long 
enough  to  prevent  use  by  the  hither  transfer  rate  modules.  To  prevent  failures  in  the  “bus  acquisition 
logic”  from  holding  the  bus  too  long,  a time-out  has  been  defined  on  the  next  master/current  master 
states. 

The  second  level  of  control  is  that  of  the  algorithms  within  the  modules.  The  signal  processing  examples 
studied  in  this  project  may  be  pipelined  so  that  centralized  timing  and  control  is  adequate.  This  type  of 
control  is  quite  desirable  since  it  simplifies  the  design  and  analysis  of  the  control  facility.  This  type  of 
control  facility  is  described  in  further  detail  later  in  the  text.  'Fhe  study  of  the  switching  system  example 
indicated  a desire  for  distributed  timing  and  either  centralized  or  decentralized  control.  The  interrupt 
port  on  the  BEU  allows  entry  to  the  controller  from  any  module  in  the  system.  This  provides  for  exis- 
tence of  either  of  the  two  control  types.  When  using  decentralized  timing  with  centralized  control,  the 
contention  and  queueing  within  the  control  module  is  complicated  and  requires  careful  analysis. 

A.  1.2  Bus  Architedure  Use 

Tlte  use  of  the  architecture  for  the  algorithm  or  functional  level  modules  allows  for  a low  transfer  rate  of 
data  and  control  on  the  bus.  During  the  module  partitioning  phase  of  the  design,  trade-offs  can  be  made 
between  demands  placed  on  the  module  control  and  data  rates  on  the  bus.  Two  main  factors  need  to  be 
considered  during  this  partitioning.  The  Tint  is  to  try  to  partition  modules  to  minimize  the  requirements 
placed  on  common  facilities  such  as  a controller  or  a common  data  memor>'.  The  second  is  to  try  to 
minimize  the  rate  of  data  flowing  from  one  module  to  the  next.  These  requirements  are  based  on  trying 
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to  reduce  the  bus  bandwidth  used  by  each  module  and  to  simplify  the  control.  This  does  not  always 
yield  a minimum  hardware  solution;  and  if  it  is  determined  that  the  bus  is  lightly  loaded,  then  common 
facilities  can  be  used  more. 


One  hazard  exists  in  using  more  common  facilities.  The  greater  dependence  one  module  places  on  another 
module  or  facility,  the  harder  it  is  to  re-use  the  module  in  another  application  or  to  change  che  module 
later  in  the  life  cycle  of  the  equipment. 

A.  1.3  Functional  Description 

Figure  A. 1-1  is  a block  diagram  of  Iht  parallel  non-dedicated  bus  architecture  as  .might  be  applied  in 
modular  signal  processing.  The  architecture  employs  three  general  functions:  Timing  and  Control, 
Algorithm  Modules,  and  the  Transfer  Bus  Facility.  Section  A. 1.4  of  this  document  describes  the  opera- 
tion and  use  of  this  architecture. 
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The  following  describes  the  three  general  functions: 

A.  Ti.ming  and  Control  (deHnid  as  an  example  for  use  with  the  signal  processing  system) 

Real  time  drives  a time  base  which  directs  a control  CPU  (via  interrupts)  to  initiate  various  computa- 
tions within  the  modules.  The  computations  are  suppoited  all  or  in  part  by  modular  algorithm  units. 

B.  Algorithm  Modules 

All  module  inbirfaces  include  Interrupt,  Address,  Status,  Control,  and  Data.  Bus  Modules  are  separ- 
ately intemipte.d  via  the  BEU  by  the  control  processor  to  initiate  computation  and  transfers.  This 
action  defu;  the  method  of  hardware  communication  with  software.  A second  type  of  communi- 
cations is  tn...  'software  modules  existing  within  the  same  computer.  If  the  module  interface  is  still 
defined  as  an  ii'"  errupt  vector  address,  then  the  module  is  called  by  branching  to  that  vector  address. 
Many  sorts  of  multitask  executives  may  be  defined  w'^hin  a single  computer  but  will  not  be  addres- 
sed in  this  description.  In  this  example,  each  .nodule  acts  as  a slave  during  data  input  and  a master 
dunng  data  output. 

C.  Transfer  Bus  Facility 

The  Transfer  Bus  Facility  is  described  in  more  detail  in  Section  A.1.4.  The  Bus  Exchange  Unit  (BEU) 
is  the  communication  port  to  tiie  Tr.ansfer  Bus.  !t  can  be  defined  in  a modular  .sense  such  that,  for 
the  simplest  case,  a module  would  connect  directly  to  the  'fransfer  Bus  with  the  BEU  only  providing 
isolation,  or  in  the  most  complex  case,  the  BEU  would  provide  for  bus  to  bus  communication  with 
DMA  control  facilities.  The  BEU  pi:'ovides  the  following  functions  in  the  general  case  but  can  be  con- 
structed of  a sub-set  of  these  functions; 

1.  Data  rate  buffering 

2.  Address  translation  between  busses  for  interprocecsor  cc«nnections 

3.  DMA  control 

4.  Bus  Isolation 


fim 
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Figure  A.1-1.  Block  Diagram  of  a Bus  Multi-mc,lule  Architecture. 


5.  Bus  Width  Translation 

6.  Bus  Acquisition  Logic 

7.  Interrupt  Masking 

Figure  A. 1-2  is  a block  diagram  showing  the  logic  (approx.  30  SSI  and  MSI  ICs)  required  for  any 
Module  which  wishes  to  be  a Bus  Master  (See  Section  IV)  and  control  data  transfer  on  the  bus.  This 
Bus  Acquisition  Logic  would  be  duplicated,  with  the  DMA  control  function  residing  between  the  two 
identical  blocks,  for  the  most  complex  case.  This  represents  a total  of  approx.  90  SSI  and  MSI  ICs. 

A.  1. 4 Principles  of  Operation 

A.  Transfer  Bus  Facilities 

The  single  bus  operates  with  a single  path  for  address,  data  and  control,  connecting  all  modules  of 
the  system.  The  bus  operates  in  a master-slave  relationship.  At  any  point  in  time,  at  most  one  device 
can  have  control  of  the  bus.  Bus  communication  is  inter-locked  so  that  for  each  control  signal 
issued  by  the  master  (controlling)  device,  there  must  be  a response  from  the  slave  (addressed)  device 
in  order  to  complete  the  transfer.  Therefore,  communication  is  independent  of  response  time  of  the 
master  and  slave  devices,  or  the  physical  bus  length.  This  asynchronous  operation  precludes  the  need 
for  transmitting  a master  clock  to  all  devices,  thereby  allowing  them  to  operate  at  their  maximum 
speed. 

Priority  on  the  bus  is  established  by  wiring  position  on  the  bus.  The  priority  structure  determines 
which  module  is  to  be  granted  control  of  the  bus.  Every  module  which  is  capable  of  becoming  bus 
master  is  assigned  a priority.  When  two  or  more  modules  request  simultaneous  use  of  the  bus,  the 
highest-priority  requestor  is  granted  control. 

The  request  and  granting  of  bus  mastership  is  performed  on  an  independent  set  of  bus-acquisition 
lines.  While  one  device  is  using  the  bus,  the  next  bus  master  can  be  assigned.  This  overlap  allows 
successive  data  transfers  by  different  bus  master  devices  to  occur  with  minimum  del.'iy. 

1.  Bus  Acquisition 

Elefore  a device  can  proceed  with  a data  transfer,  it  must  become  bus  master.  To  become  next 
master,  a device  must  request  control  at  the  bus,  be  granted  next-master  status,  and  wait  for 
the  current  master  (if  any)  to  relinquish  control.  In  general,  once  a device  has  taken  control,  it 
may  remain  master  for  as  many  transfers  as  desired  but  in  the  signal  processor  case,  it  is  felt 
that  single  transfer  will  be  adequate  since  no  overhead  is  required  to  re-acquire  bus  mastership. 
This  allows  the  highest  priority  device  only  50%  of  the  bus  bandwidth. 
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Figure  A.1-2.  Block  Diagram  of  Bas  Master  Interface  Logic. 
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The  sequence  of  l>ecoming  a bus  master  can  best  be  understood  by  referencing  Figures  A.  1-3. 

A. 1-4  and  A. 1-5.  Figure  A. 1-3  shows  the  module-to-bus  interface  with  the  signals  used  for  bus 
access.  Figure  A.  1-4  shows  a typical  bus  wiring  arrangement  to  illustrate  ihe  priority  concept 
of  a module  establLshed  by  electrical  chaining.  Figure  A. 1-5  is  a state  diagram  that  can  be 
referencerl  in  the  following  description  of  the  bus  acquisition  .sequence. 

The  following  signals  are  used  for  bus  acquisition  and  defined  as  follows: 

a.  RIIQF  - The  Bus  Request  Line  is  as.serted  by  a module  to  reque.st  bus  mastership.  A 
module  may  a.ssert  BRQF  any  time  the  seize  line  (BSZF)  is  high. 

b.  BGIF  - A chain  of  Bus-Grant  lines  provide  priority  control  over  which  device  is  to 
liecome  the  next  master.  The  highest  priority  device  receives  BGQF  which  is 
identical  to  BRQF,  {.see  Figure  4). 

c.  BSZF  - When  a device  has  accepted  a grant,  it  becomes  next  master  and  notifies  all 
other  devices  by  asserting  the  bus  seize  line.  These  other  devices  inhibit  their  request 
until  BSZF  returns  high. 

d.  BBSYF  - The  bus  busy  line  is  asserted  by  a device  after  it  has  been  granted  next- 
master  status  and  when  BBSYF  is  high.  It  is  released  by  the  device  after  it  has  trans- 
ferred its  data. 

The  signal  sequence  is  shown  by  the  state  diagram  of  Figure  A.1-5  and  proceeds  as  follows, 
starting  from  State  0. 

a.  Module  I needs  control  of  the  bus.  When  BSZF  is  high,  it  asserts  BRQF  (State  1 ). 

b.  BRQF  is  passed  through  all  modules  of  higher  priority  and  is  received  at  Module  I as 
a low  to  high  transition  on  BGIF  signaling  bus  grant  (State  2). 

c.  Since  Module  1 is  requesting,  it  keeps  its  Bus-grant  output  (BGi+lF)  high,  blocking 
the  grant  from  lower  priority  modules. 

d.  Module  I is  now  the  Next  Master.  It  waits  for  the  Current  Master  (if  any)  to  set 
BBSYF  high.  Module  I then  asserts  BBSYF  and  clears  BRQF. 

e.  Module  I waits  for  BGiF  to  return  high.  It  then  releases  BSZF  to  enable  other 
Modules  to  become  Next  Master.  (State  3). 

f.  When  Module  i has  completed  its  transfer  of  data,  it  sets  BBS Y F high  to  allow- 
another  module  to  become  Bus  Master  (State  4 to  idle). 

2.  Data  Transfer  Operation 

As  was  staU*d  earlier,  before  a module  may  proceed  with  a data  transfer,  it  must  become  Bus 
.Master.  Once  it  has  been  granted  bus  mastership,  the  module  Uikes  control  of  the  control  lines. 
The  following  signals  are  used  in  a data  transfer  sequence. 

a.  ABl  5F  - AB09F  - The  16  address  lines  are  used  by  the  master  device  to  select  the 
slave  with  which  it  will  communicate. 

b.  DB15F  • DB(K1F  - The  16  data  lines  are  used  to  transfer  data  (in  parallel)  lietween  the 
master  and  the  slave. 
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lOWRF  - The  state  of  lOWRF  determines  the  direction  of  data  transfer,  which  is  with 
reference  to  the  master:  A write  (lOWRF  low)  is  from  Master  to  slave;  A read  is  from 
slave  to  master. 

lORQF  - The  I/O  request  line  is  a.sserted  by  the  master  to  indicate  to  the  slave  that  it 
should  proceed  with  a data  transfer. 

lORPF  ■ The  I/O  reply  line  is  asserted  by  the  addressed  slave  in  response  to  the 
Master’s  request.  Its  assertion  indicates  that  the  slave  has  captured  the  data  or  gated 
the  reau-datu  to  the  bus. 


With  the  above  definitions  of  the  signal  lines,  the  timing  sequence  of  a read  and  a write  sequence 
can  be  examined.  Figure  A.  1-6  shows  the  control  line  sequence  for  a write  operation,  and 
Figure  A. 1-7  shows  the  control  line  sequence  of  the  read  operation.  The  times  shown  are  for 
an  assumed  bus  propagation  delay.  The  arrows  between  events  denote  a cause  effect  relationship 
and  imply  a non-negative  time  delay. 

B.  System  Timing  Control 

The  timing  and  control  of  a single  bus  architecture  has  an  unlimited  number  of  variations  po.ssible. 

The  one  being  investigated  was  chosen  to  simplify  the  control.  It  takes  advantage  of  the  fixed  rate 
proce.ssing  inherent  in  signal  processing  tasks.  Signal  processing  also  tends  toward  a pipeline  process 
which  allow.s  for  an  orderly  flow  of  information  from  one  module  to  the  next.  The  executive  chosen 
relies  on  hardware  (or  programmable  hardware)  to  produce  the  real  time  intervals  used  for  task 
scheduling.  Each  interval  is  identified  with  a unique  code  or  interrupt  vector  which  identifies  various 
tasks. 

1 . Software  Control 

The  control  software  is  divided  into  three  sections,  task  .scheduler,  task  queuing,  and  task 
dispatcher,  as  shown  in  Figure  A. 1-8. 
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Operation  of  the  control  section  assumes  foreground/background  processing.  The  background 
processing  (task  dispatcher)  looks  at  the  task  queue  and  generates  control  interrupts  to  the 
various  .system  .modules,  informing  them  to  start  processing  tasks.  These  interrupts  also  cau.se 
the  transfer  of  data  from  one  module  to  the  next.  If  timing  constraints  within  a module  are 
severe,  a double  buffer  concept  will  lie  u.sed  for  passing  data  between  modules.  The  control 
section  will  normally  .specify  memory  addresses  for  u.se  by  a module.  Using  the  double  buffer 
concept,  this  address  would  only  be  a starting  location,  with  the  module  using  an  index  to 
specify  addressing  from  the  sUrting  location. 

The  foreground  processing  (tasking  scheduler)  is  started  by  an  interrupt  from  the  timing  .section. 
Thi.s  interrupt  is  interpreted,  and  the  defined  tasks  > • placed  in  the  task  queue.  Upon  comple- 
tion of  this  sequence,  background  processing  is  res  c. 
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Figure  A.  1-7.  Control  Line  Sequence  for  a Read  Operation. 


Figure  A.1-8.  Timing  and  Control. 


2.  System  Interrupts 

There  are  two  types  of  interrupts  within  the  system.  The  first  is  the  interrupt  group  used  to 
drive  the  Control  Software  as  described  above,  and  the  second  are  those  interrupts  generated  by 
the  Control  Software  to  inform  the  system  modules  to  .start  u task.  The  latter  interrupts  appear 
as  vectors,  with  the  data  interface  used  to  specify  the  vector  address.  The  control  module  must 
first  cycle  through  the  Bus  Acquisition  sequence  before  issuing  an  interrupt.  The  bus  interface 
logic  associated  with  each  hardware  module  monitors  vector  addre.sses.  When  an  a.ssigned 
address  is  detected,  the  interrupt  signal 's  pa.ssed  to  the  appropriate  module.  Upon  receivn.g  the 
interrupt,  the  module  will  acknowledge  the  interrupt  and  the  .sequence  is  complete,  allowing 
the  control  module  to  release  the  Bus  Acquisition  Logic.  Under  special  conditions,  a single 
vector  address  can  be  assigned  to  more  than  one  module.  In  this  case  one  of  the  modules 
acknowledges  the  interrupt  and  the  rest  of  the  modules  must  unconditionally  respond  ti;  it. 

C.  Error  Monitoring 

A certain  amount  of  error  monitoring  equipment  has  been  specified  as  part  of  this  sy.stem.  Two 

classes  exist,  the  first  Ls  error  detection  logic,  and  the  second  is  error  recovery  logic. 

1.  Error  Detection  - The  first  level  of  error  detection  is  by  time-out  on  a data  transaction.  The 
Bus  Acquisition  line  is  monitored  in  the  timing  and  control  logic,  and  if  the  time  that  any  given 
module  is  connected  to  the  bus  exceeds  the  time-oui,  a bus  error  is  declared.  A second  type  of 
error  detection  involves  the  use  of  Tri-state  transceivers  with  parity  generation  circuits  ind>»’ed. 
This  allows  generating  the  parity  across  both  addresses  and  data  by  a master  device.  The  i ontroi 
unit  then  monitors  data  and  address  on  the  Mne  receivers  and  declares  a bus  error  if  there  is  a 
mismatch. 

2.  Error  Recovery  • Two  levels  of  enor  recovery  are  defined.  The  first  is  a Bus  Error  Interrupt 
(BEIF)  sent  to  all  modules  if  a time-out  occurs.  This  is  used  to  clear  a master  from  the  bus  if  a 
failure  occurs. 

The  second  level  is  used  to  initialize  modules,  or  isolate  modules  with  failed  bus  drivers.  To  do 
this,  a switchable  power  connection  needs  to  be  made  to  the  bus  driver  circuits.  A module 
address  would  uniquely  identify  the  drivers  to  be  turned  off  and  the  parity  checking  circuits 
would  check  for  a clearing  of  the  failure.  This  logic  would  only  be  on-line  and  automatic  in  a 
system  with  distributed  processing  since  a failure  of  a bus  module  in  a non-redundant  system 
causes  down  time.  It  is,  hov/ever,  useful  to  retain  this  hardware  for  fault  isolation  in  any 
single  bus  systems  to  minimize  down  time. 
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X.2.1  General 

In  a serial  bus  intorconiioetion  system,  morlules  are  connected  using  a senai  line,  or  lines,  for  the  transfer 
of  data  and  centre'  messages.  The.se  me.s.sage  types  may  be  sent  on  different  lines,  or  time-division  and/or 
frequency-division  multiplexed  onto  '.he  same  line.  Multiplexing  may  also  be  used  to  increase  the  capacity 
of  the  lines.  The  main  attraction  of  a serial  bus  is  that  very  few  lines  connecting  module.-)  are  nccc.ssary, 
which,  in  a physically  dispersed  system,  will  greatly  lower  costs. 

A. 2. 2 System  Components 

The  system  described  here  is  based  on  the  MITRE  Project  2290  Proposal  (M74-225),  a serial  system  using 
two  CATV  coaxial  cables  connected  at  one  end  by  repeaters,  with  modules/devices  t^.pped  into  both  lines 
(Figure  A.2-1 ).  A number  of  busses  are  frequency  multiplexed  onto  the  cable,  with  each  bus  (frequency 
band)  time  division  multiplexed.  One  bus,  the  “Control  Channel”,  is  for  control  functions.  In  addition 
one  or  more  frequency  bands  are  used  for  data  transfer.  The  control  partitioning  is  such  that  each  module 
addition  does  not  require  more  hardware  than  is  necessary  to  interface  the  module  to  the  bus,  unless  more 
bandwidth  is  required.  In  that  case,  another  frequency  band  could  bo  added  with  the  addition  of  a 
repeater  for  that  frequency  band.  The  elements  of  the  system  are  further  described  belowh 

A.  Repeaters  (Figure  A.2-2) 

One  repeater  is  required  for  each  frequency  band  used.  Each  repeater  includes  a modem  and  st'^rage 
needed  to  synchronize  input  and  output  messages.  Synchronization  is  achieved  by  writing  into  or>° 
buffer  while  outputting  another  buffer  to  the  outbound  channel.  A third  buffer  is  idle  at  this  time, 
but  will  output  at  the  next  frame  time,  while  the  one  that  previously  output  will  now  receive  from 
the  inbound  cable.  The  control  channel  repeater  also  contains  Master  Clock  Timing  and  the  frame 
sync  generator.  Timing  at  each  Module  Interface  Unit  (MIU)  is  derived  from  a single  source,  e.g. 
derived  from  the  bi-phase  PSK  signal  transmitted  by  the  repeater  for  each  bus,  and  generatec  f' ' 
Master  Clock  Timing. 

B.  Ampltfien 

Amplifiers  are  required  to  boost  the  signal  when  a .set  amount  of  loss  has  occurred  aion*,.  path. 
e.g.  20db.  It  is  proposed  that  the  present  wideband  distribution  amplifiers  used  in  CATV,  which 
have  an  established  hi|^  reliability,  would  be  ideal  for  this  application. 

C.  Taps 

The  taps  used  are  simple  passive  devices,  similar  to  those  used  in  the  CATV  industry. 

O.  Module  Interface  Unit  (Figure  A.2-3) 

The  Module  Interface  Unit  (MIU)  contains  the  modems,  logic  for  control  decoding  and  data  handling, 
and  an  I/O  adapter  which  interfaces  a device/module  to  the  coax  cable.  This  unit  is  rather  complex 
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Figure  A. 2-3.  Module  Interface  Unit  Block  Diagram. 


(ovor  90  MSI  and  .'10  SSI  ICs)  and  this  complexity  constitutes  part  of  the  cost  trade-off  with  other 
architectures.  The  MIU  is  broken  down  into  three  sections:  Control.  Data,  and  I/O. 

2 . Control 

The  control  .section  of  the  MIb'.  on  the  left  .side  of  FiKure  A.2-.3.  includes  the  control  channel 
modem,  counters  to  keep  track  of  transmit  and  receive  slot  numbers  and  the  bit  count  within 
each  slot.  These  are  .synchronized  by  the  frame-sync  detector  and  the  me.ssa>{e-sync  detector, 
res{H>ctively.  A series  of  decoders  extract  command  information  from  a variety  of  control 
messages  (Figure  A. 2-4);  this  information  is  then  routed  to  various  parts  of  the  MIU,  and  to 
the  module/device  attached  to  the  MIU. 

2.  Data 

The  data  section,  like  the  control  section,  contains  a receive  bit  counter  and  me.ssage-sync 
detector.  Message  sync  is  separate  for  each  data  channel  to  allow  for  differential  delay  between 
the  control  channel  and  the  data  channel.  Receive  and  transmit  slot  comparators  monitor  the 
slot  count  continuously  (counted  in  the  control  section)  and  determine  the  a-ssigned  slot  to 
receive/transmit  from  a slot  assignment  command.  The  data  section  derives  the  timing  for  the 
I/O  section,  according  to  the  speed  required  for  receiving  and  transmitting  dat-?.  Two  dual- 
memories. each  one  slot  in  length,  act  as  a buffer  between  the  I/O  and  the  data  modems.  Dual 
memory  is  needed  so  that  one  memory  may  be  connected  to  the  daui  channel,  while  the  other 
is  connected  to  the  I/O. 

3.  I/O 

The  I/O  adapter  logic  provides  two-way  interface  between  the  data  and  control  .section  and  the 
module/device  that  is  connected  to  the  MIU.  The  main  function  of  the  1 O section  is  to 
exchange  information  between  the  data  memories  described  above  and  the  device. 

Typically,  in  each  direction,  a dual  character  register  is  used  for  this  task.  The  interface  to  the 
device  from  the  dual  registers  may  be  serial  or  parallel.  'J'he  receive  I/O  logic  "filters”  on 
message  tags  (Figure  A.2-51  in  accordance  with  commands  obtained  from  the  control  section 
of  the  MIU.  'fag  ‘‘filtering”  can  be  commanded  into  a disabled  mode,  wherein  t.ag  characters 
would  not  be  examined.  Additionally,  referring  again  to  Figure  .-\.2-3,  the  I/O  adapter  must 
provide  a link  for  request-me.ssage  and  device  status-mes.sage  characters  to  get  to  the  control 
section  and  for  device  command  characters  to  Iw  delivered  to  the  connected  device. 

K.  Bus  System  Control : Technical  Control,  Procc.ss  Control 

1.  Technical  Control  examines  hardware  functions  including  monitoring,  as.se.ssment.  and  control 
of  the  network  operation  relating  to  bus  u.sage.  System  components  under  Technical  Control 
include  the  bus  cable,  MIUs.  repeaters.  I/O  interfaces  and  terminal  devices  {external  control 
only).  Technical  Control  is  perfonned  by  built-in  equipment  in  the  .MIU  and  a Technical 
Controller  which  is  connected  m the  network  as  one  of  the  modules, 'device.*;.  'I'he  Technical 
Controller  only  communicates  through  the  control  bus. 
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2.  I’roa>ss  Control  roooivcs  proco.s.sing  requosls,  assesses  the  requirements  to  execute  the  job,  assigns 
the  necessary  devices,  and  oversees  (he  processing.  The  Proce.ss  Control  communicates  any  failures 
or  blockages  it  encounters  to  the  Technical  Control,  which  may  allow  process  control  to 
rea.ssign  equipment  or  time  slots. 

3 Technical  and  process  control  may  be  implemented  in  a single  minicomputer  with  the  software 
for  the  two  sections  separated,  or  by  two  small  minicomputers,  each  dedicated  to  one  part  of 
the  control. 

A . 2 J Messane  Formats  ( Figures  A . 2-4  and  A . 2-5 ) 

These  are  two  major  message  formats  used  in  the  digital  system.  Data  and  Control.  Plach  message  occupies 
one  time  slot  (314  hits  long)  and  begin  and  end  with  an  8-bit  guard  band.  Each  me.s.sage  al.so  contains 
an  8-bit  synchronization  sequence. 

.A.  Data  [D]  Messages 

Data  messages  arc  defined  as  those  which  contain  data  to  be  processed  by  the  rnodules/devices.  They 
will  only  be  transmitted  on  the  data  bu-sses.  The  standard  format  (top  of  Figure  .A. 2-4)  uses  34  bits 
for  lag  and  256  bits  for  data.  Me.s.sage  tags  are  used  to  addre.ss  specific  MIUs  and/or  to  identify  data 
content  (Figure  A. 2-5). 

B.  Ckmirol  Messages 

Control  bus  command  and  control  message  formats  use  the  290  bits  (256  + 34)  as  illustrated  in  the 
remaining  entries  of  Figure  A. 2-4.  Control  Me.ssages  are  broken  down  into  two  groups;  network 
control  me.ssages  and  operational  control  nie.ssages.  Eight  bits  are  used  to  determine  the  type  of 
control  me.ssage  being  received. 

1.  Network  Control  |n1  Me.ssages  are  used  for  the  technical  monitoring  assessment  and  control  of 
the  entire  bus  .system'. 

2.  Operational  Control  |('j  Me.ssages  provide  the  means  for  transmitting  mission-oriented  control 
information  over  the  data  distribution  (control  channel  only)  system.  All  control  transactions 
directly  involving  operational  data  or  processes  are  performed  using  category  C me.ssages. 

A. 2. 4 Control  Scenario 

To  demonstrate  the  control  operation  on  the  bus,  the  system  synchronization  and  process  request 
sequence  is  expanded  in  the  paragraphs  below.  The  letter-number  combination  in  parenthe.ses;  (N5).  (Nl), 
etc.;  refer  to  the  me.s.sage  formats  of  Figure  .A. 2-4. 

A.  Seri  il  Bus  System  Synchronization  and  Slot  Acquisition 

The  repeater  for  the  common  bus  cha;inel  generates  eight  evenly  spaced  frame  synchronization 
mes.sages  (N5)  within  each  frame  (1  frame  = 65,536  .slots  = 1.4  .seconds).  When  .system  .synchroniza- 
tion has  been  achieved,  the  .system  technical  controller  (STC)  issues  status  identification  me.ssages 
(N4)  to  all  MIUs  which  assigns  each  MIU  a slot  or  .set  of  slots  on  the  common  bus  during  which 
device/module  status  messages  are  to  be  .sent  to  the  STC,  :us  well  as  the  tag  to  use.  During  the  same 


Figure  A. 2-4.  Serial  Bus  Mes.sage  Formats. 


Figure  A.2-5.  Message  Tag  Format. 


frame,  the  S’l’C  issues  request  identification  messages  (N4)  which  assigns  MIUs  slots  and  tags  to  be 
used  when  making  system  or  process  requests/commands.  Each  of  these  ID  messages  is  repeated 
2048  times  per  frame,  allowing  2048  MIUs  to  be  updated  each  frame.  If  there  are  less  than  2048 
MIUs.  each  iMIU  could  be  updated  at  a proportionally  higher  rate. 

After  an  MIU  receives  a status  ID  message,  it  begins  to  search  for  its  assigned  slot.  When  the  transmit 
slot  count  equals  the  status  slot  assignment,  the  MIU  transmits,  on  the  common  channel,  the  status 
message(s)  indicating  its  status  (N1 ) and  the  status  of  the  device/module  INI).  After  all  .MIUs  have 
transmitted  their  messages  and  the  STC  has  examined  them,  the  .STC  transmits  the  system  status  (Nl) 
to  the  system  process  controller  (SPG).  At  this  point  system  start-up  is  complete.  The  SPC  may  then 
accept  a process  request  from  an  MIU  (CT)  via  the  common  bus  transmitted  in  the  .MIL’S  assigned 
request  slot.  When  the  SPC  accepts  a process  request,  it  analyzes  the  request  and  determines  ( looks 
up)  the  equipment  required  and  the  information  handling  requirements.  The  SPC  may  then  transmit 
the  requirements  to  the  STC  for  allocation  of  available  resources  or  have  delegated  to  itself  control 
of  a specific  subset  of  the  modules  making  up  the  .sy.stem. 

The  controlling  unit  assigns  a bus,  slot  number,  slot  spacing,  and  tag  information  (N3)  to  each 
required  MIU  for  proper  data  flow,  and  the  SPC  transmits  any  processing  parameters  or  operational 
controls  needed  by  the  selected  units  (C2).  During  processing,  the  SPC  examines  the  operation  of 
both  modules  and  MIUs  to  verify  proper  operation  and  may  rea.ssign  resources  to  fine  tune  processing 
or  data  handling  capabilities. 

A.2.5  Conclusions 

The  system  proposed  in  the  paper,  while  allowing  for  easy  module  additions  and  inexpensive  wiring  costs, 
may  not  be  ideal  for  a modular  signal  processing  system  because  of  the  high  cost  of  the  MIU,  and  the  delay 
in  communications  between  modules  inherent  in  the  repeaters.  As  presently  implemented,  this  delay  of 
two  message  slots  (approximately  43  psec)  would  severely  impact  real-time  processing.  It  should  be  noted 
that  this  delay  would  not  interfere  with  a switching  system’s  operation.  A decrease  in  the  slot  length 
would  decrease  this  delay,  but  increase  the  overhead-data  ratio.  It  is  possible  to  remove  the  slot  storage 
in  the  repeaters  in  favor  of  a 16-bit  FIFO.  This  would  lower  the  delay  to  an  average  of  8 bits. 
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A.3  MATRIX  SWITCH  ARCHITKCTURK  DESCRIPTION 


A.  3.1  General 

The  matrix  switch  architecture  (Figure  A. 3-1)  ;s  similar  in  concept  to  the  C.MMP  multi-mini-processor 
computer  system  designed  at  Carnegie-Mellon  University.  The  difference  is  that  only  one  matrix  switch 
IS  utilized  rather  than  two,  i.e.,  C.MMP  utilized  one  matrix  switch  between  memories  and  computers  and 
a second  one  between  device  controllers  and  computers.  In  this  architecture,  the  modules,  whether  it 
be  memory,  device  controller  or  computer  are  all  connected  to  one  matrix  switch.  Thus,  each  module 
has  the  capability  to  seek  connection  to  another  module  without  use  of  a third  party,  i.e.,  a Device 
Module  can  connect  directly  to  a Memory  Module  instead  of  to  a Computer  Module  which  in  turn 
connects  to  a Memory  Module.  The  matrix  switch  itself  provides  the  access  logic  control,  contention 
resolving,  release  control,  and  line  status.  Connection  between  modules  is  a virtual  path  through  the 
Matrix  Switch  Module.  Each  module  interfaces  with  the  Matrix  Switch  Module  via  a Matrix  Interface 
Controller  (MIC).  The  MIC  (and  the  Matrix  Switch)  consists  of  a micro-computer,  dedicated  ROM  and 
RAM,  and  an  I/O  interface  with  serial  to  parallel  conversion. 

A. 3. 2 Implementation 

A.  Matrix  Switch 

1.  Hardware  Description 

The  Matrix  Switch  Module  consists  of  a Matrix  Switch  controlled  by  a processor  composed  of 
micro-computer  elements  configured  to  best  provide  the  circuit  switching  servic'’’  of  the  Matrix 
Switch  Architecture.  A block  diagram  of  the  Matrix  Switch  Module  is  shown  in  Figure  A. 3-2. 
Control  lines  are  connected  to  the  processor  and  full  duplex  data  lines  are  connected  to  the 
Matrix  Switch.  Circuits  are  virtually  ‘connected’  on  command  of  the  processor  upon  request 
of  the  calling  mo^lule.  The  processor  maintains  current  status  on  the  connectivity  and  operation 
of  each  data  line  as  well  as  the  control  lines.  Since  the  matrix  switch  is  the  common  gateway 
between  all  modules  in  the  system,  a microprocessor  with  higher  performance  and  throughput 
is  needed  to  service  all  the  system  module  intercommunications  with  minimum  overhead  time. 

A microprocessor  composed  of  INTEL’S  3000  family  of  two  bit  slice  microcomputer  chips  is 
being  considered,  using  a Schottky  Bipolar  ROM  for  program  storage,  and  an  85  ns  acce.ss  RAM 
for  data  and  status.  The  I/O  module  control  interface  provides  serial  to  parallel  and  parallel 
to  serial  conversions,  whereas,  the  interface  to  the  matrix  consists  of  a connect/disconnect 
line,  an  eight  bit  source  address  and  an  eight  bit  destination  address.  The  Matrix  Switch  may 
be  expected  to  be  composed  of  tri-state  logic  elements  configured  to  perform  logic  connections 
from  one  line  to  another  according  to  source  and  destination  addresses  from  the  matrix  switch 
controller. 
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Figure  A.3-1.  General  Matrix  Switch  Architecture. 
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Figure  A.3-2.  Matrix  Switch  Module. 


Principles  of  Operation 

The  Matrix  Switch  module  is  the  focal  point  of  all  the  system  modules,  i.c.,  all  modules  are 
connected  to  it  and  may  only  communicate  with  another  module  through  it.  It  functions 
primarily  as  a slave  device  in  that  it  perform.*:  Its  switching  functions  only  on  command  by  the 
System  Modules.  Each  control  circuit  consists  of  two  lines  providing  two  way  bit  serial 
synchronous  transmission.  I'he  I/O  interface  provides  serial  to  parallel  (8  bit)  assembly, 
allowing  the  matrix  switch  processor  to  operate  on  8-bit  assembled  control  characters,  saving 
the  processor  from  the  time  consuming  task  of  character  assembly.  The  system  modules 
request  connections,  and  the  matrix  switch  controller  obliges  if  the  requested  destination  is 
available;  otherwise  a ‘NAK*  is  returned.  Disconnections  are  made  on  request  by  the  destina- 
tion system  module  when  data  has  been  transmitted  in  it<  entirety. 

The  Matrix  Switch  processor  basically  provides  three  functions;  (a)  Monitor  for  connect/ 
disconnect,  (b)  Route  and  determine  circuit  availability,  and  maintain  circuit  status,  and 
(c)  connect  circuits  via  commands  to  the  Matrix  Switch.  Figure  A.3-3  shows  the  connection/ 
disconnection  path  logic.  Figure  A.3-4  shows  the  steps  that  occur  in  a module  connection  cycle. 


2.1  Connect/Disconnect  Monitor 

When  a circuit  is  not  connected,  idle  (or  sync)  characters  are  continuously  transmitted 
on  the  control  line  to  the  Matrix  Switch  Controller.  Idle  characters  are  also  transmitted 
back  to  the  sender.  These  idle  characters  provide  an  operational  OK  indication  on  both 
ends  of  the  control  line. 

When  a connection  is  desired,  the  module  sends  a "connect”  character  followed  by  a two 
character  circuit  address,  and  idie  (sync)  characters.  The  matrix  switch  monitors  each 
unconnected  circuit  for  a "connect”  character,  and  when  found  attempts  to  establish 
the  connection  (paragra)^  2.2). 

When  in  the  connect  condition,  the  matrix  switch  monitors  the  destination  control  circuit 
for  a disconnect  character.  Thus,  disconnection  is  controlled  by  the  destination  module. 

2.2  Route  and  Status 

When  a "connect”  character  is  received,  the  next  two  characters  are  assembled  and  used 
as  the  destination  circuit  address.  From  this  address,  its  status  table  is  obtained  and 
checked  for  connectivity.  If  no  connection  is  indicated,  an  " ACK”  is  transmitted  back 
to  the  requester  and  botli  status  tables  (source  and  destination)  are  updated  identifying 
its  connection  and  whether  it  is  the  source  or  destination  port.  A connet't  command  is 
then  sent  to  the  matrix  switch. 
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Figure  A.3.4.  Procedural  Dialogue  (Module-to-Module  Connection). 


If  the  destination  circuit  is  “busy”  or  “down”,  the  Matrix  Switch  Controller  sends  a 
‘NAK’  back  to  the  requester.  The  requesting  module  may  now  continue  requesting  a 
connection  to  the  same  circuit  or  requc.st  connection  to  a different  circuit. 

2.3  Data  Transfer 

In  this  mode,  the  Matrix  Switch  provides  point  to  point  connection  between  the  modules. 
The  Matrix  Switch  Controller  does  not  have  access  to  the  data  transmitted;  it  monitors 
for  disconnect  (control  command  from  receiving  module)  and  error  conditions. 

2.4  Status  Table 

A sample  of  the  type  of  information  maintained  in  the  status  table  (for  each  line)  are  as 
follows: 

1.  Available/Unavailable 

2.  Circuit  Connection  Number 

3.  Circuit  Down  (No  Response) 

4.  Source/Destination  Mode 

B.  Matrix  Interface  Control 

Similar  to  the  Matrix  Switch  Controller,  the  Matrix  Interface  Control  (MIC)  consists  of  a 
microprocessor  with  ROM  and  RAM  memory  and  I/O  interface.  A lesser  capacity  microprocessor 
is  used  since  the  MIC  is  only  responsible  for  one  (its  own)  high  speed  data  and  control  line.  The 
MlC's  primary  responsibility  is  to  interface  and  provide  the  protocol  (descril)ed  previously  in 
initiating  connects  and/or  disconnects  via  the  Matrix  Switch  to  other  MlC’s.  Three  general 
categories  of  MIC’s  are  proposed:  Algorithm  or  Task  Processor  Interface,  Device  Controller  Inter- 
face, and  Memory  Ck>ntrolIer  Interface.  Figure  A.3-5a,  b,  and  c show  the  three  general  module 
conflgurations.  The  I/O  interface  to  the  Matrix  Switch  is  identical  for  the  three  configurations. 

In  the  memory  module  configuration  (Figure  A.3-5b),  data  is  moved  in  and  out  of  main  memory 
from  the  RAM  via  DMA  interface.  In  this  type  module,  the  MIC  also  provides  memory  management. 
In  the  Device  Modules  (Figure  A.3-5c>,  circuit  control  and  protocol  is  provided  according  to  the 
type  of  device.  The  data  is  buffered  in  the  RAM  prior  to  .sending  to  another  module  (memory  or 
task).  In  the  task  module  (Figure  A.3-5a),  the  MIC  may  communicate  with  the  main  task  procc.s.sor 
via  DMA  or  via  program  controlled  proces.sor  to  processor  interface.  The  task  module  performs  all 
the  functions,  tasks,  algorithms  of  the  system.  It  also  may  be  u.sed  for  scheduling  and  task  queuing 
functions. 

C.  Communication  Interface 

The  lowest  level  of  communication  interface  is  at  the  data/me.ssage  level  where  information  is 
originated  at  one  point  and  received  at  another  point.  The  data/messages  are  normally  identified 
with  framing  characters  such  as  SOU,  STX,  ETX.  EOM,  etc.,  and  routing  and  .security  data  which 
provide  the  information  needed  to  process,  route,  and  transmit  the  daUkl message  to  its  destination. 


The  next  level  of  communication  interface  is  the  device  to  system  communication  level  (dashed 
lines  in  Figure  A.3-5c)  where  unique  device  protocol  must  be  adhered  to.  The  highest  level  of 
communications  interface  is  at  the  system  level  where  communications  are  generated  to  inter- 
connect various  components  of  the  system.  This  is  the  communication  level  that  is  unique  to 
the  system  architecture.  This  level  is  further  separated  into  two  suhievcls.  the  inodule  to  module 
communication  interface  and  the  module  to  matri.\  switch  control  interface,  as  described 
below. 

1.  Data  Lines 

The  transmission  mode  used  for  the  matrix  switch  system  is  a full  duplex  asynchronous 
operation  with  automatic  error  control  (module  to  module  level)  using  one  (1)  way  data 
transmission.  The  return  direction  is  used  exclusively  for  module  coordination  and  error 
control.  The  lines  are  physically  connected  between  the  system  modules  and  the  Matrix 
Switch  and  virtually  connected  via  the  Matrix  Switch. 

Serial  to  parallel  and  parallel  to  .serial  conversions  are  perforn'"d  at  each  end  of  the  lines  by 
the  system  module’s  I/O  interfaces.  Data  is  transmitted  upon  notification  by  the  Matrix 
Switch  Controller  that  the  connection  has  been  made.  The  data  is  framed  by  control  informa- 
tion as  shown  in  Figure  A.3-6.  The  module  header  (MOH  field)  is  made  up  of  .several 
characters  which  identify  the  data,  the  process,  and  the  source  module.  The  EOT  Held  is 
a single  character  which  indicates  the  End  of  Transmission.  Based  on  a 100  characters  data 
block,  the  module  header  (2  char)  and  EOT  (1  char)  overhead  would  be  about  3 percent  of 
the  transmission  time.  ACK’s  or  NAK’s  are  returned  via  the  return  direction  line. 

2.  Conuol  Line 

The  control  lines  are  also  serial  two  way  unes,  however,  they  go  no  further  than  the  Matri.\ 
Switch  Controller.  Continuous  sync  characters  are  .sent  to  and  returned  from  the  Matrix 
Controller.  Refer  to  Figure  A.3-6.  When  a connect  is  desired,  the  requesting  module  generates 
a “Matrix  Switch  Connect’’  (MSC)  request  which  consists  of  three  characters;  a ‘L\.nnect’’ 
character  followed  by  two  (2)  address  characters.  The  ceiving  module  u|K>n  receipt  of  EOT 
generates  a terminate  request.  ACK’s  and  NAK’s  are  also  returned  to  the  reque.sting  module. 
Adding  these  control  characters  to  the  transmission  time  adds  another  6^^  of  overhead. 


MST  - MATRIX  SWITCH  TfRMINArE 
ACK  ACKNOWLEDGE 

NAK  NO  ACKNOWl  EDGE  - ERROR/NOT  AVAILABLE 


APPENDIX  B 


ARRAY  PROCESSORS 


ARRAY  PROCKSSORS  FOR  SIGNAL  PROCKSSING  AND  SWITCHING  APPLICATIONS 


in  the  process  of  analyzing  alternate  architectures  for  signal  processing  systems  and  considering  the 
application  of  hardware  types  for  module  implementation,  the  array  processor  was  seen  to  provide  a 
“multi-module”  function  in  many  signal  processing  situations  Because  the  array  architecture  is  not 
as  modular  as  the  others  considered,  it  was  not  included  in  the  basic  studies  which  are  the  subject  of 
the  body  of  this  report.  However,  its  architecture  is  worth  discussion  for  application  to  signal  processing 
tasks  wherein  the  total  level  of  system  expansion  may  be  accurately  forecast  (e.g.,  a unit  whose  applica- 
tions could  range  between  a voice  encoder  and  a compatible  data  modem). 

In  addition,  a parallelism  between  the  array  processor’s  address  proce.ssing  function  (to  be  described)  and 
the  message  routing  functions  of  switching  systems  was  noted.  This  similarity  is  described  briefly  at  the 
conclusion  of  this  appendix.  Further  investigation  of  these  application  areas  is  an  appropriate  topic  for 
related  study. 


Introduction 

Array  processors  are  a very  efficient  means  of  implementing  digital  filters  and  other  functions  common  to 
signal  processors.  This  is  because  the  architecture  of  the  array  processor  (Figure  B-1 ) has  been  optimized 
for  performing  arithmetic  (and/or  logical)  operations  on  a predeterminable  sequence  of  data  points 
(memory  locations). 


! > 
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Conversion  of  the  continous  real-time  signal  input  into  arrays  is  the  main  task  of  the  Control  and  I/O 
processor.  Further,  because  the  data  is  to  be  operated  on  in  a pre-determinable  sequence,  an  addre.ss 
proces.sor  is  used  to  generate  this  sequence  and  supply  the  needed  arguments  to  and  take  the  results  of 
calculations  from  an  arithmetic  (logic)  processor. 

The  generalized  array  processor  implements  the  function  y = F(x)  where  y and  x are  vectors.  The  number 
of  elements  in  y is  not  necessarily  equal  to  the  number  of  elements  in  x.  The  arithmetic  processor  per- 
forms unary  or  binary  operations  on  the  elements  or  pairs  of  elements  in  x.  The  addre.ss  processor 
handles  the  indexing  implicit  in  the  operation.  Since  the  arithmetic  operations  use  and  generate  data  in 
a predeterminable  sequence,  the  address  processor  can  be  calculating  addresses  for  the  next  data  point(s) 
while  the  arithmetic  processor  is  working  on  the  current  one(s).  A vector  dot  product  s = a.b^Sajbj  is  a 
.special  case  of  the  generalized  y = F(x).  This  equation  shows  up  frequently  in  signal  proce.ssing  and 
sjiecifically  in  digital  filter  expre.ssion.  It  may  be  noted  that  to  evaluate  this  expre.ssion,  the  arithmetic 
processors  need  only  to  add  and  multiply  and  the  address  processor  does  simple  indexing.  It  .may  also 
be  noted  that  the  array  processor  can  handle  multidimensional  arrays  by  treating  them  as  appropriately 
long  vectors  and  using  nested  levels  of  indexing  in  the  addre.ss  processor. 
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Cumnion  Problem  Areas  in  Array  Processors 

In  various  array  processors  that  were  studied,  three  areas  were  noted  that  frequently  cause  difficulties. 
These  areas  are  I/O,  modularity,  and  programming.  It  may  be  further  noted  that  deficiencies  in  these 
areas  are  not  a necessary  result  of  the  array  processor  architecture,  but  seem  to  arise  from  the  concen- 
trated effort  on  the  part  of  the  designer  to  obtain  maximum  internal  operating  speed.  In  some  cases 
this  effort  has  been  so  concentrated  that  the  other  areas  have  been  effectively  ignored.  In  an  array 
processor,  performance  need  not  be  sacrificed  to  improve  the  other  factors.  The  other  factors  simply 
need  to  be  given  more  consideration  than  has  been  typical. 

Input/Output 

Array  processors  arc  very  efficient  at  processing  data  once  it  is  in  data  memory  or  a scratchpad,  but 
frequently  getting  the  data  in  and  out  of  ihe  array  proce.ssor  is  slow  and/or  difficult. 

Analog  I/O  is  inherent  in  a complete  signal  processor.  Typically  the  input  signal  is  a receiver’s  i.f.  or 
baseband  output,  its  a.g.c.  signal,  and  the  output  of  other  external  sensors.  The  proce.s.sor’s  analog 
output  is  usually  a modulating  signal  and  frequently  a variety  of  control  voltages.  With  this  in  mind, 
techniques  for  implementing  analog  I/O  were  investigated.  The  class  of  problems  wherein  a single 
processing  module  is  the  sole  or  predominant  user  of  the  signal  in  its  original  form  is  of  special  interest 
for  two  reasons:  (1)  Many  signal  proce.ssors  Ht  this  class  of  problems;  and  (2)  Practical  conclusions  may 
be  made  about  a feature  of  the  system  architecture. 

(1)  Frequently  an  analog  signal  is  digitized  and  applied  to  a digital  filter.  The  output  of  the  digital 
filter  is  then  used  .for  further  processing.  Similarly,  a serial  bit  stream  may  be  generated  and  applied 
to  a digital  Alter  for  waveshaping  (bandwidth  compression)  before  conversion  to  an  analog  signal. 

(2)  Analog  I/O  should  be  handled  directly  by  the  module  rather  than  attaching  the  analog  I/O  to  a 
common  intermodule  communication  port.  Analog  sample  rate  is  often  comparable  to  intermodule 
communication  rate  and  attaching  the  analog  I/O  to  a common  port  unnecessarily  absorbs  I/O 
bandwidth  on  the  port. 

Implications  of  this  conclusion  will  be  discussed  further  in  a later  paragraph.  In  any  event,  I/O  should  be 
a natural  feature  built  into  an  array  processor,  and  not  something  tacked  on  as  a necessary  afterthought. 

Modularity 

Can  array  processors  be  modular?  At  the  conceptual  level  they  are.  An  array  processor  is  a multiprocessor 
configuration,  and  each  processor  can  be  thought  of  as  a module.  Furthermore,  a means  of  modular 
expansion  would  seem  to  be  possible.  E.G.,  a simple  but  nontrivial  form  of  an  array  processor  contains 
an  arithmetic  processor,  an  address  processor,  and  a control  and  I/O  proce.ssor.  Some  array  processors 
use  multiple  arithmetic  units.  Some  add  a second  address  processor.  One  address  processor  then  main- 
tains an  input  queue  for  the  arithmetic  processor(s)  and  the  other  one  maintains  the  output  queue. 
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The  following  areas  present  difficulties  with  modularization: 

Processor! Processor  interaction 

Multiple  address  processors  tend  to  be  highly  interactive. 

Mutiiple  datapaths 

Full  utilization  of  arithmetic  units  requires  multiple  memory  modules  and  the  ability  to  simulta- 
neously route  data  between  multiple  pairs  of  arithmetic  units  and  memory  modules.  This  creates 
a complex  set  of  switchable  data  paths  and  a complex  control  problem  for  the  address  processor(s). 

When  modules  are  highly  interactive  and  interconnect  is  complex,  modular  expansion  at  anything  other 
than  the  conceptual  level  is  very  difficult. 

Programming 

For  reasons  related  to  the  above  hardware  difficulties,  most  array  processors  are  difficult  to  program. 
Highly  interactive  processors  must  be  concurrently  programmed.  This  is  further  complicated  by  the 
pipelining  that  is  usually  done  within  array  processors  to  increase  their  speed.  It  is  not  unusual,  for 
example,  for  the  programmer  to  have  to  explicitly  request  a memory  access,  three  machine  cycles  prior 
to  an  instruction  that  uses  data  read  from  memory.  The  pipelining  of  memory  accesses  can  be  made 
transparent  to  the  programmer  if  a means  exists  for  deflning  the  arrays  and  the  associated  addressing 
algorithms  prior  to  execution  time.  If  the  address  processor  is  made  to  be  data  driven,  then  pairs  of 
arithmetic  and  address  processors  need  not  be  programmed  concurrently.  The  address  processor  is 
simply  a slave  to  data  requests  from  the  arithmetic  processor. 

A Solution 

Figure  B-2  is  a block  diagram  of  an  array  processor  configuration  which  includes  a natural  means  of 
doing  I/O,  which  has  two  levels  of  hardware  modularity,  which  promotes  modular  software,  and  which 
is  easy  to  program.  In  this  configuration,  arithmetic  and  control  functions  are  performed  by  the  main 
processor.  Data  Fetch  and  I/O  functions  are  performed  by  the  address  processor.  This  provides  a very 
simple  and  effective  means  for  the  array  processor  to  do  I/O.  I/O  devices  simply  make  data  requests  to 
the  address  processor.  The  address  processor  then  services  these  requests  just  as  it  would  a data  request 
from  the  arithmetic  processor.  Multiple  array  processors  may  be  connected  together  via  the  inter- 
processor  bus.  Communication  between  anay  processors  occurs  whenever  a main  processor  specifies 
an  access  of  an  array  which  resides  in  the  data  memory  of  a different  array  processor.  The  address 
processor  services  data  requests  from  the  bus  exchange  unit  in  the  same  manner  as  any  other  data  request. 
Note  that  the  I/O  mechanisms  in  this  configuration  meet  the  requirements  given  in  the  earlier  section  on 
I/O.  When  multiple  array  processors  are  used  in  a system,  the  dedicated  I/O  ports  are  used  to  bring  the 
I/O  directly  into  the  array  processor  that  is  the  sole  or  primary  user  of  the  I/O.  The  I/O  is  not  placed  on 
the  interprocessor  bus. 

The  top  level  of  modularity  for  this  configuration  i.s  that  is  provides  a means  for  easily  connecting  multiple 
anay  processors  together  via  the  interprocessor  bus  to  form  a larger  system.  In  fact,  other  types  of 
processors  could  also  be  connected  to  the  interprocessor  bus. 


B-4 


r 


j V 


i 

II 


PROGRAM 

MEMORY 


A/D.  D/A.  ETC. 


MAIN 

PROCESSOR 


PORT 

ADDR 


2% 


V 

DATA  ^ 

\ / 

A 

V 


FLAGS 


BUS 

EXCHANGE 

UNIT 


2§ 


1/interprocessor\ 

BUS y 


DEDICATED 
I/O  REGISTERS 

16- WORD 

REGISTER 

FILE 

NONDEDICATED  I/O 
lINTERPROCESSOR) 
REGISTERS 

I 


DATA 


PROGRAM 

MEMORY 


h- 


COMPOSITE 

MEMORY* 


DATA  TRANSFER  REQUESTS 


PORT  ADDRESS 


n 


A ADDRESS 
PROCESSOR 




FORMATTER 


~1 

I 

1 

J 


DATA 

MEMORY 


A 

V 


DATA 


12577^ 


'COMPOSITE  MEMORY  It  INCLUDED  ONLY  IF  THERE  IS  A REQUIREMENT 
TO  BE  ABLE  TO  WRITE  INTO  PROGRAM  MEMORY 
**A  FORMATTER  IS  INCLUDED  ONLY  IF  THERE  IS  A REQUIREMENT  FOR 
FORMAT  CONVERSION  SUCH  AS  BETWEEN  FIXED  POINT  AND  FLOATING 
POINT  FORMATS. 


Figure  B-2. 
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This  configuration  also  has  a second  level  of  modularity  in  that  it  allows  multiple  address  processors  to 
be  used  to  increase  address  processing  speed.  The  address  processors  do  not  interact  with  each  other 
except  that  they  contend  for  common  data  memory.  The  address  processors,  therefore,  do  not  have  to 
be  programmed  concurrently.  In  fact,  if  the  address  processors  are  identical  and  each  contains  all  of  the 
necessary  address  algorithms  and  array  definitions,  then  the  very  existence  of  multiple  address  processors  is 
transparent  to  the  programmer.  Whenever  a data  request  is  made,  the  first  available  address  processor 
will  acknowledge  and  process  the  request.  To  the  rest  of  the  system,  the  multiple  address  processors 
look  like  a single  high  speed  address  processor. 

Multiple  address  processors  become  desirable  in  two  situations:  (1 ) The  array  processor  requires  a large 
amount  of  I/O;  (2)  A very  fast  main  processor  is  used.  Using  multiple  address  processors  in  the  first  case 
is  a simple  extension  of  the  requirement  stated  earlier  that  I/O  must  not  overload  a common  facility. 

In  both  cases,  the  capability  for  modular  expansion  at  the  address  processor  level  makes  it  easier  to 
achieve  optimum  cost  vs.  performance. 

There  are  cases  where  nonidentical  address  processors  may  be  desirable.  Dedicating  an  address  processor 
to  the  servicing  of  particular  ports  makes  a slight  reduction  in  necessary  hardware.  Address  processor 
program  memory  requirements  may  be  reduced  if  each  address  processor  services  only  a subset  of  the 
total  number  of  defined  arrays.  The  implications  that  nonidentical  address  processors  have  on  the 
software  is  discussed  in  a later  paragraph. 

The  following  program  for  the  array  processor  shows  how  array  definition  is  accomplished  and  explicitly 
performs  the  dot  product  of  two  vectors.  Note  that  the  pipelining  of  the  data  fetch  is  transparent  to 
the  programmer,  and  that  the  main  processor  and  address  processor  are  not  programmed  concurrently. 

In  fact,  a certain  amount  of  modularity  is  inherent  in  this  program.  Not  only  are  the  address  processor 
and  main  processor  coded  independently,  but  the  different  address  algorithms  to  be  executed  by  the 
address  processor  are  also  coded  independently. 
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A brief  description  of  some  of  the  instructions  follows  the  sample  program 

DEFINE  ADDRESS  ALGORITHM  1 > 

instruction  statements  I 


DEFINE  ADDRESS  ALGORITHM  N 


DEFINE  ARRAY  1 

parameter  statements 


ADDRESS  PROCESSOR 
FUNCTIONS 


DEFINE  ARRAY  N 


START:  READ 

ARRAYl  VIA  PORTl 

READ 

ARRAY2  VIA  PORT2 

WRITE 

ARRAYS  VIA  PORTS 

DOT:  CLR 

R1 

LOOP:  MOVE 

PORTl, A 

MULT 

PORT2.A 

ADD 

A,R1 

TEST 

ARRAYEND 

IF  FALSE  GO  TO  LOOP 

MOVE 

Rl, PORTS 

other  proceMing 


MAIN  PROCESSOR 
CONTROL  FUNCTIONS 


A 


MAIN  PROCESSOR 
ARITHMETIC  FUNCTIONS 


J 


WAIT  FOR  FRAME  TIME 
GO  TO  DOT 


Instruction  Description: 


DEFINE  ADDRESS  ALGORITHM 

Instruction  statements  following  this  definition  statement  generate  code  for  the  Address  Processor’s 
program  memor>'.  The  address  processor  executes  these  instructions  whenever  the  a.-ithmetic  processor 
accesses  an  array  which  ases  this  algorithm  to  determine  the  addresses  of  elements  in  the  array. 

DEFINE  ARRAY 

Parameter  statements  following  this  definition  statement  generate  entries  in  an  array  definition  block  to 
reside  in  the  address  processor's  program  memory.  The  array  definition  block  contains  the  following 
information. 

Address  (in  data  memory)  of  the  first  word  of  the  first  clement  of  the  array. 

Access  control  word.  (May  point  to  a list  of  users  authorized  to  read/write.) 

Address  (in  address  processor’s  program  memory)  of  the  address  generation  algorithm. 

Algorithm  dependent  parameters  — number  of  words  per  element,  element  spacing,  physical  length 
of  circular  buffer,  etc. 

READ 

Moves  a word  from  the  main  processor  to  PORT  0 of  the  16  word  register  file.  This  word  contains  the 
number  of  the  array  definition  block  and  the  data  port  number.  Upon  receipt  of  this  control  word,  the 
address  processor  initiates  the  appropriate  address  algorithm  and  moves  the  first  word  of  the  array  from 
data  memory  to  the  specified  data  port. 

WRITE 

Same  as  READ  but  no  data  is  moved 
TEST  ARRAYEND 

' est  a completion  flag  associated  with  the  register  file  which  is  maintained  by  the  address  processor. 
IMPACT  OF  .MULTIPLE  ADDRESS  PROCESSORS  ON  SOFTWARE 

As  mentioned  earlier,  the  existence  of  multiple  identical  address  processors  has  no  impact  on  the  software, 
but  nonidentical  address  processors  do.  If,  for  example,  a unique  address  processor  is  dedicated  to  I/O 
and/or  interprocessor  communications  and  another  one  is  used  to  service  the  main  processor,  the  impact 
on  the  software  is  minimal.  The  only  requirement  is  that  a means  must  exist  for  directing  the  DEFINE 
ADDRESS  ALGORITHM  and  DEFINE  ARRAY  statements  to  generate  code  for  a particular  address 
processor.  If,  however,  an  address  processor  is  dedicated  to  particular  main  processor  ports,  the  pro- 
grammer must  be  constantly  aware  of  which  ports  are  being  used  in  order  to  insure  parallel  processing.  If 
the  address  processors  are  further  specialized  so  that  not  all  array  definitions  and/or  algorithms  are 
present  in  each  processor,  there  Ls  a significant  additional  burden  placed  on  the  programmer. 
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i\s  was  mentioned  earlier,  multiple  address  processors  become  desirable  in  two  situations:  ( 1 ) the  array 
processor  retiUtres  a large  amount  of  I/O;  (2)  a very  fast  main  processor  is  used.  The  second  case  is  of 
interest  since  there  are  ways  other  than  brute  force  to  build  a fast  main  processor.  Let  us  reconsider  the 


main  program  loop  in  the  sample  program. 


LOOP: 


MOVE  PORTl.A 
MULT  PORT2.A 
ADD  A.Rl 
TEST  ARRAYEND 
IF  FALSE  GO  TO  LOOP 


A main  processor  that  executed  these  instructions  could  generally  he  supported  by  a single  address 
processor  that  had  a good  instruction  set  and  a cycle  time  equal  to  that  of  the  main  processor.  If, 
however,  a three  address  machine  were  used  for  the  main  processor;  the  main  program  loop  could  be 
written  as  follows: 

LOOP:  A=PORTl*FORT2 

Rl-Rl+A 

IF  (ARRAYEND-FALSE)  GO  TO  LOOP 

The  three  address  machine  accomplishes  the  task  in  three  machine  cycles  instead  of  five  and  would  require 
two  “ordinary”  address  processors  to  support  it.  A.side  from  its  improved  speed,  the  use  of  a three  address 
machine  is  desirable  for  the  main  processor  for  its  ease  of  programming.  As  can  be  seen  from  the  sample 
programs,  the  three  address  processor  uses  a higher  level  machine  code.  The  three  address  machine  is 
particularly  feasible  in  this  array  processor  configuration  since  its  addresses  are  port  and  internal  register 
addresses  rather  than  memory  addresses.  Since  fewer  bits  are  required  for  each  address  specification, 
the  instruction  word  can  actually  be  shorter  in  length  than  a traditional  two  address  machine  that  makes 
direct  memory  accesses. 

ARRAY  PROCESSORS  A.M)  SWITCIIIiNG  SYSTEMS 

Array  processors  were  investigate*!  because  of  their  direct  applicability  to  signal  proce.ssing.  As  the 
modular  architecture  study  progressed,  however,  it  became  apparent  that  array  processing  techniques 
could  be  applied  to  switching  systems  too.  The  address  processor  can,  fo'  <.;«ampie,  do  dynamic  memory 
allocation  and  can  ser\-ice  the  traditional  “mailboxes”  in  a manner  that  is  transparent  to  the  rest  of  the 
system.  Various  table  lookup  and  search  algorithms  could  al.so  be  implemented.  The  algorithms  would 
be  easy  to  access  from  the  arithmetic  processor  but  further  investigation  would  be  necessar>'  to  develop 
programming  techniques  that  are  natural  to  u.se  and  that  would  result  in  ptirallel  proce.ssing  in  the  address 
and  arithmetic  processors.  Without  such  techniques,  the  arithmetic  proces.sor  might  end  up  idling  while 
it  waits  for  the  address  processor  to  find  a table  entry.  This  may  be  able  to  be  justified  on  the  basis  of 
ease  of  programming  but  it  certainly  doesn’t  utilize  the  full  potential  of  the  array  proces.sor.  Further 
stuay  in  this  area  is  indicated.  Further  study  is  also  needed  in  the  area  of  definition  of  instruction  sets 
for  the  address  processor  and  arithmetic  processor.  For  switching  systems,  the  high  speed  multiply  and 
other  such  extended  arithmetic  capabilities  that  are  highly  desirable  for  signal  proce.s.sing  might  well  be 
sacrificed  in  favor  of  powerful  logical,  bit  manipulation,  and  decision  making  instructions.  In  the  address 
processor,  capabilities  for  multilevel  indirect  addressing  with  both  preindexing  at.d  postindexing  are 
probably  desirable.  As  was  stated  b<;fore.  further  study  is  indicat<*d. 
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Cl  GKNFRAL  DESCRIPI’IOiN 

The  specification  for  a module  is  an  iterative  function.  The  first  step  is  definition  of  the  algorithm  and 
definition  of  the  preliminary  design  specifying  as  many  parameters  as  possible.  As  the  modeling  of  the 
equipment  progres.ses  and  as  the  design  progresses,  more  of  the  parameters  become  apparent  and  can  be 
specified.  Eventually  the  parameters  in  the  module  definition  will  be  ased  to  form  the  body  of  a module 
specification  used  to  completely  define  a module  physically,  electrically  and  functionally.  .Some  cases 
exist  when  a module  is  completely  specified  initially.  This  case  exists  when  more  of  the  external  opera- 
ting environment  for  the  module  is  known.  In  this  case,  the  problem  is  only  one  of  designing  a module 
to  meet  the  specincation.  The  following  sections  describe  which  module  parameters  need  to  be  specified. 

C2  MODULE  DESCRIPTION 

Description  of  the  function  performed,  i.e..  Output  = Input  x Transfer  Function.  Input/Output  oriented 
block  diagram  identifying  data,  control,  and  timing  requirements.  A discussion  related  to  this  diagram 
should  indicate  the  system  designer’s  options,  e.g.,  where  certain  control  signals  are  always  required; 
where  they  are  not.  This  discussion  will  also  stipulate  external  requirements,  e.g.,  on  the  system  executive; 
it  should  also  de.scribe  the  implications  of  software  implementation.  It  should  specify  the  type  of  control 
and  the  number  and  type  of  interrupts,  if  required.  For  software,  the  control  entry  requirements  must  be 
specified.  Data  formats  and  number  systems  used  should  be  specified  as  the  design  progre.s.ses. 

C.3  MODULE  INPUTS 

(a)  Format 

(b)  Input  Port,  master/slave,  access  time 

(c)  Multiplex  requirements,  e.g.,  is  more  than  one  signal  input  via  the  same  ix>rt? 

(d)  Timing  (rate),  timing  will  frequently  vary  with  application.  Specify  input  rale  in  norm.ilized 
terms,  e.g.,  10  input  words  are  required  i>er  output. 

(e)  Timing  (sequence),  relationship  of  data  and  control  inputs.  (Design  Note:  De.scription  .'ehould 
specify  speed  independency  whenever  possible). 

(f)  Addressing,  identify  ail  vector  addresses  used  for  control,  all  data  input  addresses  and  engineering 
inputs  which  can  be  to  specify  relative  addressing  within  the  module. 

(g)  Other  inputs,  if  non-address  inputs  are  used,  sfiecify  their  reason  for  occurrence,  the  frequency, 
format,  etc. 
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(a)  Format 

(b)  Output  Port,  master/slave.  aca»s.s  time 

(c>  Multiplex  control  requircmeiiLs  when  multiple  outputs  share  a single  port. 

(d)  Timing  (rate),  normalized  (.see  Inputs) 

(e)  Timing  (sequence),  dependencies  (see  Inputs) 

(f)  Addressing,  identify  all  vector  addre.s.ses  used  for  control  of  other  modules,  all  data  output 
address  used  in  either  ma.ster  or  slave  states. 

(g)  Other  outputs,  if  non-addressed  outputs  are  used,  stipulate  their  reitson  for  occurrence,  their 
frequency,  format,  etc. 

C..'i  TRANSFKR  CHARACTERISTICS 


(a)  Throughput  delay.  This  will  typically  indicate  how  many  input  words  and  commands  arc  required 
to  produce  an  output.  (Processing  Time) 

!b)  Scaling.  If  not  clearly  defined  in  C.2  and  C.3,  data  dependencies  should  be  explicitly  defined  here, 

(c)  Fault  detection.  Consider  various  input  failure  modes  (see  below)  and  define  output  indication. 


Input  Failures 

(1)  Power 

(2)  F.<icility  signals 

(3)  Out  of  .sequence  controls 

C.6  OTHER  REQCIREME-VTS 


Indication 

(Meter,  I,amps. 

& other  Indicators) 


This  .section  specifies  ail  power  supply,  cooling  or  other  external  requirements  the  module  ha.s.  This 
section  is  ••.xpanded  a.s  the  module  design  progres.«es. 
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ARCHITECTURE  SELECTION  CRITERIA 


Whenever  the  importance  of  individual  line  items  in  the  selection  criteria  may  be  dependant  on  the  area  of 
application,  the  selection  criteria  were  independently  applied  to  two  categories  of  applications  — switching 
systems  (SW)  and  signal  processing  systems  (SP).  Each  of  these  categories  is  broad  enough  to  be  of  general 
interest  but  narrow  enough  to  allow  reasonably  precise  comparisons.  Those  line  items  which  are  considered 
to  be  particularly  important  to  each  of  the  categories  are  indicated  by  two  columns  of  asterisks  at  the  left 
hand  edge  of  the  table  of  selection  crikcria. 
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SW 


SP 


COST.  The  cost  to  be  considered  is  true  life  cycle  cost  including  costs  of  acquisition,  operation, 
and  logistic  support. 

1.  Required  hardware/software  (overhead) 

(A)  What  is  needed  to  support  minimum  configuration? 

(B)  What  is  needed  to  support  each  additional  module? 


2.  Flexibility 

If  a system  design  is  flexible  enou^  to  be  used  for  other  systems,  then  development  costs 
can  be  amortized  over  more  than  one  contract.  Production  costs  for  the  first  contract 
may  be  handled  in  a similar  manner  if  the  increased  flexibility  results  in  a reduction  of 
production  costs  when  mulitple  contracts  are  considered. 


(A)  How  well  are  widely  varying  performance  requirements  handled? 

(B)  Is  it  easy  to  go  from  the  general  to  the  specific? 

(This  is  related  to  ease  of  design.) 

(C)  Is  the  specific  still  general  relative  to  the  class  of  problems? 

3.  Adaptable  within  a configuration 

If  one  assumes  that  it  will  be  desirable  or  necessary  to  improve  (modify  operation  or  add 
features)  a given  system  during  its  expected  lifetime,  then  the  adaptability  of  the  system 
has  a significant  impact  on  life  cycle  cost  of  the  system.  Furthermore,  a system  which  may 
be  easily  improved  will  probably  have  a longer  life  expectancy. 

(A)  How  is  growth  in  hardware  or  software  achieved?  (New  design  or  repetition?) 

(B)  How  can  field  changes  be  tested  and  implemented? 

(C)  What  limits  does  the  design  place  on  upper  signaling  rates,  response  times,  dynamic 
range,  memory  or  device  addressability,  terminal  I/O,  etc.?  (Allowance  for  two  to 
one  growth  over  the  lifetime  of  signal  processing  equipment  is  probably  adequate.) 
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3.  Adaptable  within  a configuration  (Continued) 
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(D)  Can  the  design  accommodate  technology  change  in  signaling  techniques, 
filtering  techniques,  A/D  dynamic  range,  etc.?  (What  is  the  probability  of 
.such  change?) 

Ease  of  design 

(A)  What  hard  ware/so  ft  ware  exists  that  is  similar  or  identical  to  the  required 
modules? 

(B)  Can  “standard”  components/languages  be  used? 

(C)  Are  both  the  hardware  and  software  natural  to  use  or  does  one  have  to 
continually  be  “clever”? 

(D)  Can  it  be  tested  simply? 

( 1 ) Can  it  be  tested  incrementally? 

(2)  Can  it  be  easily  prototyped  and/or  simulated? 

Ease  of  documentation 

(A)  Is  a common  interface  used  for  software  and/or  hardware  modules? 

(B)  To  what  degree  is  the  hardware/software  self  documenting? 

(C)  Did  the  original  design  light  the  way  for  future  changes?  This  is  necessary 
because  personnel  will  usually  be  different  between  an  initial  design  and  the 
redesign  event. 

Manufacturability 

(A)  Is  it  state  of  the  art?  (Consideration  must  be  given  to  the  time  of  application, 
the  necessity  of  the  technique,  and  mu.st  include  an  effort  to  forecast 
industry  trends.) 

(B)  Does  the  depth  of  the  logic  require  long  test  sequences? 

(C)  Does  “cleverness”  of  the  design  require  high  level  test  technicians? 

(D)  Is  it  machine  diagnosable?  (Machine  diagnosis  may  reduce  but  not  eliminate 
the  impact  of  the  above  two  items.) 

(E)  Can  design  phase  tests  be  used  to  partially  or  wholly  satisfy  production  test 
requirement.?? 
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7.  Maintainability 


(A)  Can  fault  isolation  be  easily  achieved?  (Busses  make  this  difficult;  also  relative 
addressing  of  any  kind,  virtual  machines,  and  any  kind  of  multiplexing  is  less 
than  optimum.) 

(B)  Can  test  facilities  be  built  in  naturally? 

(C)  Cabling,  connections,  etc.  Do  these  force  unnatural  mechanical  designs  which 
are  hard  to  maintain? 

(D)  Can  the  mechanical  design  be  transferred  easily?  (This  is  a i/easure  of  the 
simplicity  of  connection.) 

RELIABILITY 

1.  Ascertain  MTBF.  (Relates  to  maintenance  costs  also.) 

2.  Ascertain  the  number  of  single  point  failure  locations.  (Probably  much  more  important 
than  basic  MTBF.) 

3.  Ascertain  types  of  failure  modes.  Failure  modes  must  identified  in  terms  of  their  system 
impact  (percent  loss  of  function).  Critical  sections  must  be  analyzed  for  failure 
detectability. 

4.  Is  the  design  pushed  to  technology  limits? 

(A)  Timing  constraints 

(B)  Environmental  sensitivity 

5.  What  is  the  maturity  of  the  technology  itself? 

PERFORMANCE 

1.  Data  processing  capability  (throughput  and  latency) 

2.  Control  requirements  (forced  overhead) 

(A)  Data  interchange  and  buffering. 

(B)  Required  protocol. 

(C)  Data  routing  requirements.  (Does  data  from  ‘a’  to  ‘b’  have  to  go  via  *c’? ) 
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CUSTOMER  REQUIREMENTS 


Power,  coolini;,  cabling 

Size,  weight,  form  factor 

Flexibility,  adaptability  (see  sections  1.2  and  1.3) 

Security 

(A)  Red/Black  isolation 

(B)  Security  to  single  point  failure 

(C)  EMI/EMC 

(D)  TEMPEST 
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SIGNAL  PROCESSING  TARGET  SYSTEM 
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'Fhe  general  class  of  signal  processing  equipment  modeled  in  this  study  is  confined  to  communication  links 
which  transfer  data  or  digitized  voice.  With  this  type  of  equipment  both  signal  proce.ssing  and  communica- 
tion proce.ssing  may  co-exist.  We  have  restricted  our  analy.sis  to  the  receive  terminal  end  of  the  .system. 
Information  which  is  input  to  this  equipment  is  carried  on  a receiver  IF  frequency  with  the  information 
bandwidth  limited  to  approximately  3 KHZ.  This  information  is  demodulated  using  complex  arithmetic 
techniques  and  proce.ssed  further  according  to  the  data  type.  Parameters  which  may  vary  within  this  type 
of  equipment  are:  information  rate,  modulation  index,  encrypted  data  or  bandspreading,  coding  tech- 
niques, error  detection  and  correction  proce.ssing,  and  me.ssage  formatting. 

The  equipment  modeled  in  this  study  receives  an  “IF’*  frequency  of  7.5  KHZ  which  is  modulated  by  a 
phase  continuous  FSK  signal  with  a modulation  index  of  0.5.  The  modulation  rate  varies  from  100  Hz 
to  1600  Hz.  Correlation  or  integration  periods  of  1/2  second  to  2 seconds  are  included  in  the  module 
library.  The  two  coding  types  considered  were  antipodal  (Complementary  Orthogonal  CO)  and  M-Ary 
where  M=65.  CJharacters  are  grouped  using  the  detected  symbol  stream  such  that  two  characters  are 
received  every  fifteen  correlation  intervals.  Appendix  I (and  Figure  I-l)  describes  a partitioning  of  this 
type  of  equipment  which  is  not  necessarily  optimum  but  provides  a basis  for  analysis  of  the  architecture 
using  the  simulation  model. 
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APPENDIX  F 

SWITCHING  TARGET  SYSTEM 


MhSS  \(;k  switch  aitmcation 
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i. 

I hf  followitiK  paraKrapjhs  d«*s»TU»‘.  briffly.  a 12-lim*  message  switch  {jrovidmg  ausU're  store-and-forward 
service  of  IkiUi  record  and  data  traffic  to  a variety  of  connecU'd  U*rminals  and  in-tween  other  switches. 
Ihis  switch  IS  similar  to  >he  TRI-TAC  Unit  Level  Message  Switch  (ULMS), 

II.  Iiilerlare  l)efiiiiti<Hi 

The  switch  interfaces  with  12  suh.scriln-rs.  a Traffic  Service  Position  |TS!»).  a Tactical  Communications 
Control  Facility  ( ICCFl,  and  another  ULMS.  Each  of  the  12  subscriber  interfaces  can  handle  either 
asynchronous  NRZ  or  synchronous  conditioned  dtpha.se  signals.  For  the  purpose  of  this  application,  an 
arbitrary-  mixture  of  these  signal  ty|M*s  are  u.sed  as  shown  in  Figure  F-1 . A mixture  of  I/O  me.ssage  rates 
.suggested  for  a test  bi-d  configuration  in  the  ULMS  s|K«cification  are  used  for  this  application.  A 
description  of  the  signals  for  each  of  the  interfac  es  are  givcm  in  the  following  paragraphs. 

A.  Sub.scriber  Interfaces  (12) 


1. 


b. 

c. 


2. 


A.synchronous  Digital  Interface 
a.  Balanced  NRZ 

Rates:  1 10,  150,  and  300  Baud 
Received  Signal 
Level:  0.05  to  3.0  Vn-p 

S'N  Ratio:  20  dB  in  .signal  bandwidth  (white  noi.se) 
Timing:  Bit-by-bit  a.synchronous.  .slart/stop  codes 
Transmitted  signal 
Level;  +0.8  to  + 6.0  Vp-p 
S/N  Ratio:  80  dB  in  signal  bandwidth 
Timing:  Bit-by-bit  asynchronous,  .slart/stop  codes 
Synchronous  Digital  Interface 
a.  Conditioned  diphase 
Rates: 

Modulated  Rate  (bps) 


d. 


b. 


600 

1200 

2-tOO 

16000 

32000 


Information  Transfer  Rate  (bps) 


600 

1200 

2100 

*8000.  16000 
*16000 


When  MR/ITR  ratio  is  2/1  ( 16/8  or  32/16)  dual  bits  (00  or  1 1 ) shall  Im»  proce.--.sed  or  generated. 
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synchronous 


f 


c.  R»*i'iMved  signal 

Lpv«‘1;  .3Vp-p  or  less  (t-apablo  of  spnsing  transmit  signal  ovpr  3200  meters  of  Wf  -10  eahle) 
S/N  Ratio;  20dB  in  signal  bandwidth 

d.  rrunsmitlod  signal 

Level:  310.3  Vp-p  terminated  in  135  ohm 
S/N  Ratio:  80  dB  in  signal  bandwidth 
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B.  Traffic  Service  Position  iTBP)  Interface 

1.  Dedicated  Termination 

2.  Asynchronous  Digital  Signals.  NRZ 

3.  110  Baud  ASCII 

4.  Mode  II  - full  duplex,  no  error  or  channel  controls 

5.  Signal  levels  as  de.scrilK.‘d  under  .Vsynchronous  Digital  Interface  paragraph  above. 


C.  Tactical  Communications  Control  Facility  (TCCF)  Interface 
1 Dedicated  Termination 
2.  Conditioned  diphase  signals 
f 3.  Rate:  2000  bits/.sec. 

\ -rl  D.  Another  UI<MS  lnU*rface 

1.  Direct  (hardware)  interconnection 
; 2.  Dedicated  termination 
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ill.  Pr«»ceMing 

A.  Message  Store  and  Forward 

The  message  switch  shall  receive  incoming  messages  and  subsequently  shall  transmit  these  messages 
directly  to  subscriber  terminals  or  to  other  message  switches  for  ultimate  transmission  to  destmiiiion 
terminals.  Traffic  awaiting  transmission  shall  be  stored  as  intransit  traffic, 

B.  Mes,sage  Security 

The  message  switch  shall  handle  the  following  classification  levels: 

TT  - TOP  SECRET 
SS  - SECRET 
CC  -CONFIDENTIAL 

LIU  - UNCLASSIFIED  , 


S’  Each  incoming  and  outgoing  channel  shall  Ije  class  marked  for  a maximum  security  level.  If  a non- 

I perishable  message  is  received  that  exceeds  the  security  class  mark  of  the  channel,  the  me.ssage  is 

I j delivered  to  the  traffic  service  position  for  disposition.  If  the  mes.soge  is  f)erishabie.  it  is  discarded. 


I 

i 
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('  I’rcccdi'm-i-  K»*aUirc 

The  Mchsajje  switch  shall  rccogni/e  five  precedence  leveK.  as  follow- • 

Y - ECP 

■/.  - FLASH 

O - I MM  EDI  A I E 

P - PRIORITY 

R - ROUTINE 

Messages  shall  he  queued  for  transmission  first  by  pr*  >eden< c level,  then  bv  order  of  arrival  .Service 
messages  shall  be  placed  in  queue  ahead  of  all  .Nubscnber-onginaled  m<  ^-dge>  (j{  equal  or  lower 
precedence  A me.ssage  in  process  of  transmis->ion  shall  not  he  interrupted  for  transmission  of 
another  message  of  any  higher  precedence  level. 

D.  Throttling 

Throttling  is  the  implementation  of  certain  procedures  to  regulate  peak  load. 

Throttling  shall  be  implemented  automata  allj  upon  reaching  preset  thresholds  for  percentages  of 
in-transit  storage  capacity  utilized.  There  are  three  threshold  levels,  each  of  which  are  adjustable  by 
the  supervisor.  Passage  of  these  levels  shall  result  in  the  reiei  tion  suc<  e-sively.  of  imoming  messages 
of  ROUTINE,  PRIORITY,  and  I.M.MED1.\  I E within  prei  edenc  e.  order  of  ivjet  tion  shall  be.  first, 
messages  originated  from  local  subx  riber  terminals,  and  se<  ond.  message-  mi  cnning  f ;m  trunk' 
FLA.SH  and  ECP  me.ssages  shall  never  be  rejected  during  any  throttling  < ondition 

E.  Processing  Capaci'y 

The  12-line  message  switch  shall  have  sufficient  pro*  es'.ng  « apa<  ity  and  message  buffering  to  handle 
concurrently  total  input  and  output  information  as  shown  below 

I sei  ond  Interval 
iH-bit  characters  I 

Input  (Receive)  .'1  k 10^ 

Output  ( .Send ) .3  x 1 0*^ 


1 hour  Interval 
I s-i>;i  ■ iiaractors  i 

2 1 .\  10® 

9 h i .X  10® 


F.  Proce.ssmg  Time 

The  message  svs-itch  shall  have  a n.ean  processing  time  of  no  m.^re  than  0 10  onds  for  ail  messages 
processed  For  ECP  and  FU,-\SM  me.ssages.  no  more  than  one  in  10^  shall  have  a proces-ing  time 
greater  than  0.50  .second  Proc  es.sing  time  is  defined  as  the  time  fru::i  rec  ejilajn  of  the  i.i't  bit  of 
F;0.M  fora  me.ssage  until  that  message  i»  placed  in  in-transit  storage  plus  the  time  from  the  instant 
of  iivailability  of  a transmission  channel  for  the  message  until  the  first  bit  of  the  SO.M.  taitu  al  header, 
or  path  field  for  the  message  is  output.  I he  time  which  a message  remains  ii.  in-iransit  storage  shall 
not  be  included  in  the  processing  time 


F-4 


IV.  Message*  Description 

A.  (’odes 

The  mes.sage  switch  shall  process  mes.sages  on  a character oriented  hasi.s.  Characters  shall  consist  of 
7 bits  of  information  and  an  8th  bit  to  achieve  odd  parity.  Lini>  and  nn‘.ssage  protocol  shall  utilize 
USASCll  characters  with  even  and  odd  parity,  respectively.  .Mes.sage  text  will  be  transparent. 


B.  Message  Protocol 

Me.ssage  protocol  elements  utilized  by  ^ub.scribers  .shall  be  a start-of-niessagc  indicator,  a tactical 
header,  and  an  end-of-me.ssage  indicator. 

1.  Start -of-.Mes.sage  Indicator  (.SOM) 

a.  Asynchronous  loops 

Four  "W"  characters,  two  carriage  return  characters,  and  two  Ime-feed  characters 

b.  Synchronous  loops 

SOM  IS  inherent  in  the  line  protocol  employed  between  the  subscriber  device  and  the 
switch  (See  SKCTION  VWI). 

2.  Tactical  Header 

a.  I’recedence  (1st  character) 

b.  Classification  ( Security  i (2nd  and  3rd  characters) 

c.  Me.ssage  Type  (4th  character) 

P - Perishable 

.\  - Nonperishable 

d.  Message  Text  Code  and  Format  (5th  character) 

A.  ASCII;  teletypewriter 

B.  Binary  text;  standard  EDPE  system  parity  chec.k  for  entire  message  text 

C.  Unspecified;  fixed  record  length.  80  characters  jjer  record,  .senes  format 

D.  Unspecified;  variable  record  length,  up  to  1200  aljiha-numeric  chai’acters  |5er  record. 

E.  Binary  text;  odd  EDPE  system  parity  check  for  text  charai  lers  only 

e.  RESERVED  - NULL  (6th  - 8lh  characters) 

f.  Originating  .subscrilier  terminal  tactical  routing  indicator  (9th  ■ 11th  characters! 

3 allowable  ALPHA  characters  (Q  disallowed) 

g.  Start -of  routing  indicator  ( 1 2tb  character) 

HYPHEN  (-) 

♦h.  Destination  addressee  terminal  tactical  routing  indicator  1 13th  character  - as  required  I 
Three  allowable  .-M.PH.-\  characters  each.  45  character-,  max  (Q  disallowed). 

1.  End-of-rounting  indicator  (I  chtiracter.  position  a."  required) 

PERIOD  (.! 


I ll 


*^Ma.\imum  numtier  of  d«‘stination  addre.s>os  allowed  .shall  be  l.a  I'he  length  o(  the  tactu  al 
header  will  vary  from  16  to  .58  characters,  depending  on  the  number  of  dcMnia'.ion  .iddre-v^er. 

3.  End-of-Message  Indu-ator  (EOM) 

The  EO.M  .shall  be  Qt^t^X-X-X  where  .XXX  is  the  tai  ti.  a!  n.uting  iiidn  tor  of  the  originating 
sulxscriber  termiiml. 
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\ , MfSHagc  Valitiation 

All  suliscnber  originated  me.s.sagcs  slsalt  In-  validated  by  tlu>  message  switrh.  Validation  i-hecks  shall  !)'•  as 
follows: 

A.  SOM  Indicator 

B.  Procedem  (• 

C.  Class!  fit-af  ion 

D.  Message  lypo 

1C.  Message  Text  Code  and  For.mal 

F.  Originating  Subscriber  Terminal  Tactical  fvoulnig  Indicator 

G.  Stait-of-Kmiling  Indicator 

M.  Ue.stination  .Addre.ssee  ■Tfirminai  Ta<  tical  Routing  lndic:ito‘(>) 

I.  End-of-Kouting  Indicator 
.1.  Message  Text 

(Parity-odd:  max.  chars.  -1200} 

K.  End-oi'-Messagt*  Indicator 

VI.  I.oggiii" 

The  message  switch  .shall  maintain  a log  for  nonperishable  me.s.>ages.  It  .shall  he  logically  and  eh’cln.  ally 
indejX'tident  of  intransit  storage.  Information  contained  in  the  log  'hall  he  as  follows: 

A.  Path  Field 

B.  Tactical  Header 

C.  Time  of  Receipt 

D.  Time  and  manner  of  disposition  for  eaelt  message  copy. 

VII.  .Mzxiimiiii  Me.s,«age  Traffic 

A.  20000  perishable  me.ssage.s  handled  on  I.ine  1 during  busy  hour 

1.  The  mes.sages  arrive  at  regular  intervals,  one  every  180  milli.seconds 

2.  Each  nie.ssage  is  one  80  chara<-ter  block  long 

B.  2500  non-|H*rishablfi  me.ssage.s  are  sent  on  all  other  lines  during  busy  hour 

1 . .Mes.sages  arrive  tit  random  intervals. 

2.  These  mes  .ages  range  in  length  from  I to  H>  bloeks  long,  with  a mean  of  I blocks  (.'{20  charact<*rsi. 

VIII.  .Message  laivmii 

ThP basic  message  layout  (Figure  F-2;  reflfcCs  the  me-vsage  a.s  it  will  ap{>ear  in  mam  memory  (.A.SCll  i.  A 
line  handler  (see  Figure  J1 ) is  resjionsible  for  ref«>rmatting  each  ine.s.sage  it  receives  in  this  format  in  mam 
memory  The  location  for  the  me.s.sage  in  main  memory  is  acquired  hy  the  line  handler  from  its 
"mailbox"  The  line  handler  will  pruhahiy  begin  transfenng  the  me.ssage  to  main  memory  after  it  ha.s 
procc-s.s<;*d  the  header  and  before  it  has  received  all  of  the  me.ssage  text.  'This  implies  that  the  h;;<‘  handler 
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must  count  the  characters  in  the  message  and  set  the  message  length  field  after  the  message  transfer  is 
completed.  The  line  handler  will  also  place  a date/time  stamp  in  the  me.ssage  pn>fix.  The  date  field 
will  consist  of  the  last  digit  of  the  current  year  followed  by  the  three  digit  Julian  day.  The  arrival  time 
field  will  occupy  four  character  positions  and  contain  the  time  of  day  in  hundredths  of  a second  expressed 
in  binary. 

IX.  Functional  Modules 

The  message  switch  shall  contain  the  following  functional  modules: 

A.  Line  Interface  Modules 

B.  Input  Service  Modules 

C.  Output  Service  Modules 

D.  Code  Translation  Module 

E.  Message  Storage  Module 

F.  Message  Logging  Module 

G.  Validation  Module 

H.  Routing  Module 

I.  System  Control  Module 

J.  Memory  Management  Module 

K.  Error/Recovery /Alarms  Module 

L.  initialization  Module 

M.  Diagnostics/Test  Module 


Appendix  G 

Signal  Processing  Selection 


I.  Summary 

The  architecture  used  for  the  balance  of  the  studies  of  modular  sifi(nal  processor  design  is  the  parallel  bus 
system  described  in  Appendix  A.l.  The  selection  criteria  (see  Appendix  D)  were  applied  with  the  aid 
of  a candidate  signal  processing  target  system  (Appendix  F)  by  separate  judges  in  the  areas  of  cost, 
performance,  and  reliability.  The  results  of  these  comparisons  are  shown  graphically  in  Figure  G-l  and 
G-2.  In  the  area  of  cost,  the  importance  of  u particular  line  item  is  determined  by  its  contribution  to 
total  cost.  In  the  area  of  reliability,  the  judge  also  indicated  which  item  was  most  important  and  which 
was  least  importa:it.  In  the  area  of  performance,  all  items  were  judged  to  be  equally  important.  Customer 
requirements  were  not  included  in  the  analysis  due  to  their  total  dependence  o.i  application. 

Figure  G-1  shows  the  percentage  of  the  total  score  within  each  category  attributed  to  each  architecture. 
This  figure  is  based  on  a best,  medium,  worst  scoring  for  each  line  item  in  the  selection  criteria.  It  also 
assumes  that  best,  medium,  and  worst  are  geometrically  related  (e.g.,  best  =*4,  medium  '2,  least  -1) 
characteristics.  For  raw  scores  see  Table  G-1.  Figure  G-2  serves  to  interpret  the  raw  scores  by 
indicating  the  "best/worst"  distribution  among  architectures;  perhaps  thereby  providing  a measure  of 
system  design  risk. 

II.  Architecture  Comparison  by  Cost 

When  a specific  application  is  known,  dollar  figures  can  be  calculated  or  estimated  for  each  line  item 
in  this  section.  The  importance  of  each  line  item  is  then  precisely  determined  by  its  contribution  to 
total  cost.  In  order  to  keep  this  comparison  independent  of  application,  costs  of  required  hardware 
are  given  in  terms  of  the  number  of  circuit  cards  needed  when  standard  currently  available  components 
are  used.  Costs  of  software  are  given  in  words  of  microcode,  lines  of  assembly  language,  etc.  The  level 
of  coding  assumed  is  that  which  is  commonly  used  today.  This  allows  accurate  estimates  to  be  made 
now  and  allows  for  extrapolation  of  these  estimates  to  account  for  coding  at  whatever  level  of  language 
is  desirable;  e.g.,  HOL.  To  keep  the  comparison  independent  of  system  size,  costs  are  given  on  a per 
module  basis  where  applicable.  Where  further  application  dependency  exists,  relative  trends  and 
tendencies  are  given.  Wherever  possible,  linearity  or  degree  of  non-linearity  and  the  existence  and 
magnitude  of  discontinuities  is  indicated. 

Frequently  within  this  section,  the  acronyms  BEU,  MIC,  and  MIU  are  used.  These  are  the  interface 
hardware  for  the  parallel  bus,  matrix,  and  serial  bus  respectively. 

1.  Required  Hardware/Software  (Overhead) 

A.  What  is  needed  to  support  minimum  configuration?  (Includes  interface  for  first  two 
hardware  modules) 
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Figure  G-1,  Architecture  Comparison  Summary  — Totals. 
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Bus  — Timing  and  Control  Module  (2  4x7”  cards/0-200  words  of  microcode)  -3  BEU’s 
(1  4x7”  card  each). 

Matrix  — Matrix  switch  and  controller  2-3  4x7”: cards/200- 1000  words  of  microcode). 

Serial  — Technical  and  process  control  (1  minicomputer/10,000-40.000  lines  of  assembly 
language).  3 MIU’s  (5  4x7”  cards  each)  for  technical  and  process  control  and  2 hardware 
modules,  2 repeaters  (2  4x7”  cards  each),  6 taps,  0 amplifiers. 

B.  What  is  needed  to  support  each  additional  module?  (See  also  3A) 

Bus  — 1 BEU  for  each  hardware  module  (complexity  (1-3  4x7"  cards)  depends  on  module)/ 
0-10  words  of  microcode  in  the  control  module  for  each  vector  interrupt  that  it  has  to  generate, 
I/O  support  in  other  modules  to  move  data  to/from  the  additional  module. 

Matrix  — One  MIC  per  hardware  module  until  all  ports  (16)  are  used.  Hardware  growth  than 
halts  unless  a multiplexer  or  submatrix  module  is  defined.  Potentially  the  addition  of  any 
module  (hardware  or  software)  can  require  I/O  support  from  other  modules  and  microcode 
support  in  all  MIC’s.  These  requirements  can  be  minimized  by  careful  definition  of  software 
module  interfaces  and  the  use  of  generalized  I/O  routines  in  the  MIC’s. 

Serial  ~ 1 MIU  and  2 taps  per  hardware  module,  2 amplifiers  per  X taps  and/or  Y ft  (20  dB 
loss),  1 repeater  per  data  channel  if  additional  bandwidth  is  required.  Technical  control  must 
be  informed  of  the  characteristics  of  eadi  new  hardware  module  and  process  control  must  be 
informed  of  the  configuration  and  procedure  for  all  new  system  tasks. 

2.  FlexibiUty 

A.  How  well  are  widely  varying  performance  requirements  handled? 

Bus  — Addition  of  new  modules  limited  only  by  bandwidth  and  addressability.  (Bus  buffers 
must  be  added  for  groups  of  100  modules.) 

Matrix  — Addition  of  new  modules  limited  by  bandwidth  and  severely  limited  by  number  of 
available  ports.  The  limited  number  of  connections  makes  it  undesirable  to  utilize  a port  for 
a low  speed  device,  but  multiplexing  multiple  low  speed  devices  onto  a single  port  causes  other 
complications. 

Serial  - Addition  of  new  modules  limited  only  by  bandwidth  (addressing  capability  is 
essentially  infinite  for  signal  processing). 
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B.  Is  it  easy  to  go  from  the  general  to  the  specific? 


Bus  — A hierarchy  of  busses  may  be  easily  defined.  This  can  be  used  to  increase  bandwidth 
and  addressability. 

Matrix  — Assuming  “smarts”  are  distributed  in  using  modules,  this  is  not  too  difficult.  The 
design  process  is  aided  by  concurrent  applications  design.  A hierarchy  of  matrices  and  sub- 
matrices can  be  defined  in  extend  addressability. 

Serial  — No.  A good  understanding  of  Technical  and  Process  Control  is  necessary  to  achieve 
efficient  interaction  of  the  module  with  them.  The  present  description  of  the  software  used 
to  implement  technical  and  process  control  is  sketchy  at  best,  but  indications  are  that  it  is  very 
general  and  very  complex. 

C.  k the  specific  still  general  relative  to  the  class  of  problems? 

J 

Bus  — Yes,  if  a hierarchy  is  used.  Also,  most  microprocessors  use  an  internal  bus  structure. 

This  says  that  one  may  proceed  firom  general  to  specific  all  the  way  down  to  this  level.  Note 
> that  in  doing  this,  the  details  of  control  of  busses  at  the  different  levels  may  be  different.  This 

increases  the  burden  of  documentation  but  allows  existing  modules  which  use  different  control 
I ' mechanir.ns  to  be  incorporated  into  a system.  It  also  allows  a “new  and  improved”  module 

which  uses  a different  control  mechanism  to  be  incorporated  into  an  existing  system. 

Matrix  — To  a limited  extent.  This  feature  can  be  strengthened  by  the  use  of:  matrix/ 
submatrix  techniques,  programmable  modules,  and  general  purpose  I.'O  routines  in  the  MIC's. 

Serial  — No.  This  system  seems  to  go  from  the  general  solution  of  all  the  problems  in  the 
universe  to  the  specific  solution  of  a particular  case  in  one  full  swoop. 

3.  Adaptable  within  a Configuration 

I A.  How  is  growth  in  hardware  or  software  achieved?  (New  design  or  repetition?  1 

Bus  — Growth  is  easy  and  cost  nearly  linear.  Slight  discontinuities  and  hard  limits  as  noted 
in  2A  and  3C.  Mechanical  design  may  impose  additional  limits.  When  a hardware/suftware 
module  is  added,  it  is  usually  necessary  for  other  modules  to  |»t>vide  I/O  support.  Costs  for 
I/O  support  approach  a square  law  relationahip  for  the  wont  case  where  all  modules 

I I intercommunicate. 

1 1 Matrix  — If  unused  ports  are  defined  in  the  original  configuration,  growth  is  easy  until  the  ports 

are  all  used.  Hardware  growth  within  the  configuration  then  ceases.  I/O  support  ^-osts  will  be 
moderate  and  nearly  linear  in  a well  designed  matrix  system.  (See  also  IB). 
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Senal  — Growth  is  easy  and  cost  nearly  linear.  Slight  discontinuities  occur  when  amplifiers 
must  be  added  to  gain  data  channel  bandwidth.  Costs  for  I/O  support  are  nearly  linear  since 
I/O  support  is  provided  by  process  control  on  a per  task  basis.  An  exception  to  this  is  the  case 
where  adding  a new  module  allows  the  system  to  do  many  new  tasks. 

B.  How  can  fleld  changes  be  tested  and  implemented? 

Bus  — Field  changes  to  the  hardware  are  reasonably  easy  as  long  as  the  mechanical  design  pro- 
vides easy  access  to  the  bus.  When  a new  module  is  .■  )ded,  a malfunction  or  design  error  in 
the  new  module  may  make  the  entire  system  inoperative.  This  risk  is  reduced  by  using  a 
standard  circuit  for  the  BEU.  Field  changes  to  the  .software  carry  a similar  nsk  of  tying  up 
the  bus. 


Matrix  — Addition  of  a hardware  module  is  easy  if  a port  is  available.  The  addition  of  .software 
modules  or  replacement  of  a hardware  module  is  also  easy.  The  risk  involved  in  such  changes 
is  very  low  since  the  matrix  provides  Isolation  between  its  ports. 

Serial  — Field  changes  are  relatively  easy.  System  down  time  for  the  addition  of  a hardware 
module  is  dependent  on  the  ease  of  installing  a tap.  Since  the  taps  provide  isolation  from  the 
serial  line  and  the  operation  of  the  MIU’s  can  be  verified  prior  to  installation,  additional  down 
time  is  unlikely.  A hardware /software  module  can  be  replaced  with  the  system  only  losing  the 
ability  to  perform  tasks  which  require  that  module. 

C.  What  limits  does  the  design  place  on  upper  signaling  rates,  response  times,  dynamic  range, 
memory  or  device  addressability,  etc.? 

These  performance  related  items  affect  cost  in  that  they  allow  an  assessment  of  the  nsk  of 
exceeding  a performance  limit  when  one  attempts  to  upgrade  a system.  Their  cost  impact 
arises  at  design/production  time  with  the  inclusion  of  the  requisite  performance  niargins. 


BUS 

MATRIX 

SERIAL  1 

Data  Rate 

Mid 

Best 

Worst  j 

Response  Time 

Best 

Mid 

Worst  1 

Dynamic  Range 

Mid 

Mid 

I 

Addressability 

Mid 

Worst 

Best  i 

U.-  , ..  ~i 

The  bus  has  a cycle  time  of  about  250n'.  mmj  uses  a 16  bit  word.  This  gives  a 64  MHz  data 
rate.  The  matrix  supports  a 16  MHz  data  rate  on  each  data  line.  As.suming  eight  paii^  of  ports 
simultaneously  conversing  and  a 3%  overhead  for  control  characters  gives  a 124  MHz  total 
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data  rate.  The  serial  system  has  an  effective  data  rate  of  7.5  MH2  per  FDM  channel.  This  limit 
is  a soft  limit  in  that  more  FDM  channels  can  be  added  at  significant  expense. 

The  response  time  of  the  bus  is  simply  its  cycle  time  (250ns).  The  turn  around  time  of  the 
matrix  is  2.5  us.  The  turn  around  time  of  the  serial  system  is  at  least  238  us. 


The  dynamic  range  of  the  bus  is  fixed  by  its  16  bit  data  word.  Multiple  words  may  be  used  to 
extend  this,  but  such  extension  is  not  trivial.  The  matrix  is  oriented  toward  the  u.se  of  eight 
bit  characters,  but  these  are  easily  manipulated  in  any  multiple  of  eight  bits.  The  serial  system 
uses  a 256  bit  block  which  in  most  cases  would  be  subdivided  into  words  of  appropriate  length. 
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The  bus  uses  a 16  bit  address.  The  matrix  can  directly  address  only  16  ports  (4  bits),  memory 
management  techniques  are,  therefore,  mandatory  in  this  sytem.  The  serial  system  has 
65,536  time  slots  (16  bits)  and  each  slot  contains  a 34  bit  tag  for  an  effective  50  bit  addressing 
capability. 

O.  Can  the  design  accommodate  technology  change  in  signaling  techniques,  filtering  techniques, 
A/D  dynamic  range,  etc.?  (What  is  the  probability  of  such  change?) 

Bus  — Yes.  The  burden  cf  change  is  on  the  modules. 

Matrix  — Yes.  The  burden  of  change  is  on  the  modules. 

Serial  — Most  technology  changes  would  affect  only  individual  modules.  Advances  in  the  area 
of  flberoptics  could  make  the  serial  communication  technique  much  more  attractive. 

4.  Ease  of  Design 

A.  What  hardware/software  exists  that  is  similar  or  identical  to  the  required  modules? 

Bus  — Much  hardware  exists  which  is  very  similar  to  that  required.  The  BCU  functions  need 
only  to  be  repackaged.  Much  software  for  bus-oriented  machines  also  exists. 

Matrix  — Matrix  systems  are  not  common,  but  they  are  relatively  easy  to  work  with  at  the 
conceptual  level. 


Serial  — Similar  hardware  is  not  well  known.  Extensive  executive  software  is  required. 


B. 


Can  “standard"  romponents/ianguagos  b«‘  used? 


}■ 


Bus  — Yes.  Bus  interfaces  which  are  implemented  with  small  scale  integrated  circuits  already 
exist.  Medium  scale  integrated  circuits  which  now  exist  may  be  used  to  improve  this  interface. 
The  bus  architecture  has  no  specialized  language  requirements. 

Matrix  - Yes.  The  matrix  controller  and  interface  units  are  implemented  with  microprocessors. 
The  language  u.sed  in  this  system  must  be  able  to  generate  efficient  microcode. 

Serial  — Yes.  This  system  uses  a mixture  of  standard  logic  elements,  standard  CATV  elements, 
and  standard  minicomputers.  To  improve  cost,  custom  large  scale  integration  should  be  con- 
sidered for  the  interface  units.  This  architecture  has  a stronger  requirement  for  a job  control 
or  process  control  language  than  the  other  two  do. 

C.  Are  both  the  hardware  and  software  natural  to  use  or  does  one  have  to  be  continually  “clever"? 

Bus  — Better  than  average.  Cleverness  is  required  only  if  bus  bandwidth  and/or  software 
execution  time  limits  are  approached.  The  hardware  module  interface  is  extremely  simple. 

A similariy  simple  software  module  interface  can  be  u.sed.  The  module  designer/programmer 
needs  to  know  very  little  about  the  rest  of  the  system.  As  is  always  the  case,  it  is  highly 
desirable  that  at  least  one  person  on  the  project  understand  the  entire  system  to  insure 
efheient  operation.. 

Matrix  — Average  design  difficulty.  Module  design  requires  .some  knowledge  of  the  .system. 

Serial  — If  the  latency  in  moving  data  and  getting  a positive  respon.se  can  be  tolerated,  the 
system  is  reasonably  natural  to  use.  Good  executive  softw.ire  i.s  the  key  to  this  factor.  For 
signal  processing  the  latency  is  unfortunately  long.  This  would  require  continual  cleverness 
and  record-keeping  to  overcome.  Module  design  requires  extensive  knowledge  of  the  system 
including  executive  .software. 

D.  Can  it  be  tested  simply? 

1.  Can  it  be  tested  incrementally? 

2.  Can  it  be  easily  prototyped  and/or  simulated? 

Bus-1.  Yes. 

2.  Yes.’ 

Matrix  — 1.  Yes.  Minimal  test  configuration  is  somewhat  large. 

2.  Probably  average. 
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Serial  1.  Yes.  Minimal  test  <-on figuration  would  be  technical  and  proce.ss  control,  and 
one  or  two  test  modules.  This  is  still  a fairly  large  collection  of  hardware  and 
software.  Specialized  exet;utive  test  software  would  1h*  very  helpful  if  not 
essential. 

2.  Coars(‘  simulation  would  be  fairly  ea.sy.  Prototyping  would  Ik*  a fairly  major 
effort. 

5.  Ease  of  Documentation 

A.  Is  a common  interface  u.sed  for  .softw'are  and/or  hardw'are  modules? 

Bus  — Can  Be.  As  an  example,  a vectored  interrupt  can  b<‘  processed  by  a dedicated  hardware 
module  or  by  a specific  software  module  within  a hardware  module. 

Matrix  — A common  hardware  interface  exists  between  the  matrix  switch  and  the  MlC*s.  The 
MIC's  are  mtcrocoded  to  meet  the  needs  ot  the  individual  module.  The  module  interface  is 
therefore  less  standardized.  Software  interfaces  can  be  standardized,  but  any  interchange  of 
software  modules  with  hardware  modules  requires  a change  to  the  task  keeper  software. 

Serial  ~ A common  hardware  interface  exists  up  to  a point.  Beyond  this  point,  the  '’flexibility” 
exists  to  tailor  the  interface  to  the  module.  It  is  presumed  that  a similar  situation  would  exist 
with  the  executive  software.  It  is  not  readily  apparent  that  the  hardware  and  software  modules 
could  be  easily  interchanged. 

B.  To  what  degree  is  the  hardware/software  self-documenting? 

Bus  — BEU’s  are  documented  once  and  then  used  by  all  modules.  High  level  language  may  be 
used. 

Matrix  - Hardware  for  a switch  is  largely  application  independent.  Hence  documentation  is 
non-recumng.  Control  software  for  signal  processing  is  not  too  bad.  MU'  hardware  is  docu- 
mented only  once.  Microcode  for  individual  MIC's  .should  b<*  very  similar. 

Serial  — Mill’s,  bus  repeaters,  amplifiers,  and  taps  are  dtK-umented  once  and  then  usi-d  by  all 
modules.  Complexity  of  the  MIU’s  is  a dtsadvantage.  “Cleverness"  as  de.scnlx*d  m -tC 
increased  difficulty  in  documenting  individual  modules.  Tailoring  of  the  MIC's  caus**-*  some 
problem.s.  If  the  exec  software  is  pr<i|>erly  written,  the  u.ser  should  lie  able  to  program  proc«^s 
control  functions  in  a ver>'  high  level  language.  It  may  b<‘  more  difficult  to  use  a high  level 
language  to  write  the  exit-  software 
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C.  Did  thp  original  design  light  the  way  for  future  changes?  This  is  necessary  because  |)ersonnel 
will  usually  be  different  between  an  initial  design  and  the  redesign  event. 

Bus  — Better  than  average  because  of  existing  documentations  and  simplicity  of  architecture. 

Matrix  — Yes,  if  reasonable  documentation  support  is  maintained. 

Serial  — Can,  but  complexity  of  the  system  would  require  the  original  designer  to  be  very 
conscientious  in  his  documentation  effort,  particularly  in  the  area  of  software  documentation. 


6.  Manufacturability 

A.  Is  it  state-of-the-art?  (Consideration  must  be  given  to  the  time  of  application,  the  necessity  of 
the  technique,  and  must  include  an  effort  to  forecast  industry  trends.) 

Bus  — No. 


i 
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Matrix  — Not  state-of-the-art.  The  elements  that  make  >p  the  matrix  and  its  controller  are 
benefitting  from  increased  use  of  large  scale  integration. 

Serial  — No,  but  it  might  be  if  optical  fiber  techniques  are  used.  The  serial  system  should 
benefit  from  expected  advances  in  the  state-of-the-art  in  this  area.  The  present  high  speed 
modems  used  are  clo.ser  to  being  state-of-the-art  than  the  elements  used  in  the  other  systems. 


B.  Does  the  depth  of  the  logic  require  long  test  sequences? 

Bus  - Test  .sequences  are  determined  by  modules.  Almost  no  length  is  added  to  the  lest 
sequences  as  a result  of  the  parallel  bus  architecture. 

Matrix  — Test  may  be  complex  - more  so  than  a parallel  structure  at  least.  The  larger  amount 
of  software  required  may  be  a benefit  in  larger  production  runs. 

Serial  — Serial  interfaces  tend  to  generate  long  test  sequences. 

C.  Does  “cleverness”  of  the  design  require  high  level  lest  technicians? 


Bus  Not  usually.  Certain  types  of  failures  on  the  bus  are  difficult  to  isolate.  Data  trans- 
actions on  the  bus  can  be  difficult  to  ob.serve.  The  use  of  logic  state  analyzers  significantly 
reduces  these  problems. 


Matrix  Normal  test  personnel  requiremenl.s  are  adequate.  The  matrix  doesn’t  have  the 
iffif^-ullies  of  the  bus.  but  its  circuitry  is  more  < omplex. 
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Serial  — Cleverness  as  described  in  4C  may  require  some  high  level  test  technicians.  The  mixture 
of  logic  type  components  and  CATV  type  components  found  in  this  system  will  cause  some 
additional  difficulties. 

D.  I.s  it  machine  diagnosable?  (Machine  diagnosis  may  reduce  but  not  eliminate  the  impact  of  the 
above  two  items.) 

Bus  --  Machine  diagnosis  of  module  failures  is  possible.  Machine  diagnosis  of  bus  failures  is 
difficult  and  special  provisions  in  the  hardware  are  required  to  isolate  such  failures. 

Matrix  — Machine  diagnosis  of  module  failures  is  possible.  Perhaps  trouble  at  the  module 
interface  (and  internal)  level  would  require  manual  intervention.  Monitoring  of  control  line 
protocol  and  data  line  activity  is  “built  in”. 

fierial  — Machine  diagnosis  of  module  failures  is  possible.  Some  such  features  are  “built  in”  to 
the  system.  Failures  in  the  transmission  medium  should  be  easy  to  isolate  manually..  Failures 
in  technical  control  could  be  difficult  to  find  unless  an  independent  console  is  attached  directly 
to  the  minicomputer  that  provides  the  centralized  portion  of  this  function.  Such  a console  and 
possibly  additional  I/O  devices  would  allow  extensive  self-test  routines  to  be  implemented. 

E.  Can  de.sign  phase  tests  be  used  to  partially  or  wholly  satisfy  production  test  requirements? 

Bus  — Very  little  testing  is  required  beyond  the  te.sts  of  the  individual  modules.  A system 
level  “exerciser"  type  of  diagnositic  should  be  easy  to  write  for  this  system. 

Matrix  — Yes.  Design  and  production  test  require  module  simulation.  This  is  a design  time 
requirement  but  is  transferable  to  production.  Production  test  requirements  for  MIC’s  and 
for  the  Matrix  Controller  may  exceed  those  i.i  the  design  jihase. 

Serial  — Due  to  the  complexity  of  the  system,  production  testing  will  probably  need  to  be 
much  more  exten.sive  than  that  used  in  the  design  phase. 

7.  Maintainability 

A.  <Can  fault  isolation  be  easily  achieved?  (Hu.sses  make  this  difficult;  also  relative  addressing  of 
any  kind,  virtual  machines,  and  any  kind  of  multiplexing  is  less  than  optimum.) 

Biis  — Faults  within  modules  that  don’t  place  a fault  on  the  bus  itself  are  ea.sy  to  isolate.  Faults 
on  the  bus  can  be  very  difficult  to  isolate. 
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Matrix  Fault  isolation  will  ht*  very  good  (rapid)  to  circuit-related  (i.e.,  channel)  failures. 
Control  switch  functions  would  be  only  average  unless  a “diagnostic”  module  were  included  in 
the  system. 

Serial  --  Mo.st  faults  within  modules  are  ea.sy  to  isolate.  This  system  makes  it  very  unlikely  for  a 
module  to  place  a fault  on  the  serial  bus.  Most  failures  of  amplifiers  or  repeaters  can  be  quickly 
isolated  from  observing  lo.ss  of  signal  or  data.  Transmission  line  failure  can  be  easily  isolated  to 
a particular  line  .segment.  Failures  in  process  and  technical  control  may  be  difficult  but  most 
of  the.se  could  be  isolated  with  appropriate  .self-diagnostic  programs. 

B.  Can  test  facilities  be  built  in  naturally? 

Bus  ~ Yes.  A timeout  for  bus  transactions  is  built  into  the  c'ontrol  module.  With  medium  scale 
integrated  circuits  that  are  now  available,  parity  generation  and  checking  can  be  added  with  no 
cost  increase. 

Matrix  - Yes.  All  control  and  data  lines  are  full  duplex  with  the  return  path  being  used  for 
control  response  and  error  control.  Sync  characters  are  transmitted  constantly  on  idle  control 
and  data  lines.  For  every  character  transmitted  a character  is  also  returned.  The  matrix  con- 
troller constantly  monitors  operations  for  validity. 

Serial  — Yes.  Some  are  included  in  the  original  definition  of  this  architecture. 

C.  Cabling,  connections,  etc.  Do  these  force  unnatural  mechanical  design.i  which  are  hard  to 
maintain? 

Bus  — The  large  number  of  wires  in  the  parallel  interface  can  cau.se  difficulties. 

> 

Matrix  — Cabling  is  better  than  average.  The  serial  nature  of  the  communications  and  the 
lower  data  rate  (i.e.,  data  rate  is  a per-channel  phenomena  — not  a total  i yield  simpler 
connections. 

Serial  — Cabling  is  very  simple.  Special  attention  must  b<*  paid  to  the  coax  connectors. 

D.  Can  the  mechanical  design  be  transferred  ea.sily?  (Thi>  is  a measure  of  the  .simplicity  of 
connection.) 

Bus  --  Yes,  but  the  large  number  of  wires  can  cause  some  problems. 
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Matrjx  - M»>chanii  al  d«*sif;n  for  expandability  is  easy  only  within  limits.  Extra  channel.s  may 
ea.sily  be  added  but  the  basic  size  of  the  switch  cannot  be  changed  in  existing  equipment.  New 
designs  could  accommodate  larger  switches  without  much  design  time. 

Serial  - Yes.  Special  attention  mu.st  be  paid  to  the  i-oax  connec-tors. 


III.  Kelaihilit> 

1.  .Ascertain  MTBF 

The  parallel  system,  using  estimated  part  counts  and  number  of  connections,  should  have  the  be.st 
MTBF.  Serial  is  ranked  second  and  Matrix  third.  Matrix  has  a poor  showing  here  because  of  the 
poor  estimated  lailure  rate  of  microproce.ssors.  (The  Matrix  system  studied  uses  one  microprocessor 
per  interface  unit  plus  one  in  the  Matrix  Switch  .Module.  The  serial  system  requires  a large  micro- 
processor or  minicomputer  for  control,  while  the  parallel  has  a much  simpler  mechanism). 

2.  A.scertain  the  number  of  single  point  failure  locations 

Because  of  the  distributed  nature  of  the  control,  and  four  cin.  uit  connections  to  the  central  bus  per 
interface  unit,  the  serial  system  rates  as  having  fewest  single  point  failure  locations.  The  matrix, 
because  of  the  complexity  of  the  central  .Matrix  Switch  .Module,  ranks  below  the  serial,  while  the 
parallel  bus  system,  with  its  relatively  high  number  of  lines,  rates  lowest.  It  should  also  be  noted 
that  this  category  is  rated  the  most  important  in  the  reliability  section. 

3.  A.scertain  the  types  of  failure  modes 

Failure  modes  must  be  identified  in  terms  of  th»*ir  .sytem  impact  (percent  loss  of  function  |.  Critical 
.sections  must  be  analyzed  for  failure  detectability. 

This  category  is  rated  ai  the  .s<>cond  itionI  important  in  this  section.  Howe'.er.  the  failure  modes  for 
all  sy.stems  ap,iear  to  identical  (failure  to  release,  failure  to  connect,  wrong  connection,  etc.). 

The  .Matrix  system  has  a better  detectability  because  of  the  one-to-one  connection  path. 

4.  l.i  the  design  pushed  to  technology  limits? 

A.  Tin.ing  Constraints 

The  .serial  system.,  bi-cuase  of  the  high  speed,  has  the  only  timing  problem  fon.een. 

B.  Environmental  .Sensitivity 

No  system  appears  to  have  any  particular  advantage  or  disadvantage. 

5.  What  is  the  maturity  of  the  technology  itself? 

The  parallel  .sy.stem  is  the  most  used  .system.-  with  most,  if  not  all.  elements  of  the  system  included 
in  MSI  and  LSI  jiarts  which  are  available  off  the  .shelf.  Tin*  Matrix  system  does  not  have  th<*  level  of 
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integration  of  the  parallel  system,  l)Ut  is  completely  digital,  and  contains  no  high  risk  developmental 
areas.  The  serial  system,  rated  lowest  in  the  category,  will  require  the  development  of  the  data 
modems. 


IV.  Perfornianre 

To  determine  the  Data  Proce.ssing  capability  each  architecture  was  considered  in  terms  of  maximum  point 
to  point  transfer  rate. 

1.  Point  to  Point  Transfer  Rate. 

Parallel  Bus  — The  transfer  rate  of  the  Parallel  Bus  approaches  a 4 MHz  transfer  rate  if  no  time  is 
allowed  for  data  set  up  in  the  modules  connected  to  it.  This  can  be  defined  as  240  nsec  + Module 
.set  up  or  access  time.  If  C-mos  modules  or  other  .slow  devices  are  u.sed  m the  module  the  bus  rate 
drops  significantly  unless  high  speed  buffering  is  provided. 
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Each  transfer  on  the  bus  consists  of  a para""i  16  bit  word  and  a 16  bit  address  (this  transfer  includes 
parity  if  so  desired). 

Matrix  — The  transfer  rate  of  the  matrix  was  investigated  using  two  approaches.  The  minimum 
hardware  approach  uses  a MOS  UARTS  which  have  an  upper  rate?  of  56  KHz.  This  yields  a transfer 
rate  of  6. IK  bytes  or  3K  16  bit-word  transfers.  The  other  extreme  u.ses  a Manchester  coded  serial 
stream  at  16  MHz.  This  yields  a 2M  byte  transfer  rate  of  1 MHz  16  bit  word  transfers  per  data  path. 
Up  to  eight  data  paths  may  be  active  at  once  in  the  16  port  matrix. 

This  approach  yields  a high  throughput  rate  at  the  expense  of  higher  hardware  co.st.  The  rating  was 
made  using  the  higher  transfer  rate. 

Serial  Bus  — The  serial  bus  was  also  investigated  using  two  approaches.  The  first  a.ssumed  only  two 
frequencies  available  in  the  FDM  system.  One  frequency  would  be  u.sed  for  data  and  the  other  for 
control.  With  a 14.8  MHz  channel,  the  transfer  rate  is  925K  16  bit  words.  With  10  channels,  this 
rate  is  925M  16  bit  words.  The  .second  approach  is  very  costly  in  hardware  but  it  should  be  noted 
that  growth  from  925  KHz  to  9.25  MHz  increases  linearly  in  cost  w’lih  increased  performance.  Thus 
rale  is  .slightly  lower  when  the  overhead  is  added  (7.54  MHz). 

The  results  of  the  comparison  in  terms  a data  transfer  rate  show  the  .Matrix  first.  The  Parallel  Bus 
second  and  the  serial  FDM/l'DM  third. 

The  second  attribute  to  investigate  in  Performance  is  the  time  to  make  or  break  a connection 
between  modules.  This  is  one  measure  of  the  efficiency  of  the  control  m«‘chanism  in  the 
architecture. 
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Control  Hoquirements. 


Parallel  Bus  — No  penalty  in  throughput  rate  is  suffered  due  to  the  control  scheme  of  the  parallel 
bus  due  to  the  “Next  Master”  and  “Current  Master”  states  of  the  bus.  Due  to  the  non-synchronoiis 
nature  of  the  data  transfers  and  the  single  communication  j>ath  pre.sent,  any  signal  proce.ssing 
implementation  using  the  parallel  bus  must  in.sure  proper  ordering  of  module  priority  on  the  bus. 
Also,  care  must  be  taken  to  insure  any  module  with  slow  acce.ss  does  not  interfere  with  a module 
with  high  data  transfer  rates. 

Matrix  --  The  matrix  system  was  again  considered  using  two  approaches.  With  the  UART  approach, 
the  time  to  disconnect  one  connection  and  make  the  next  c-onnection  (turn-around  time)  is  571  msec 
which  appears  to  be  not  useable  in  signal  processing  without  large  amounts  of  module  buffering.  For 
the  16  MHz  coded  scheme,  this  time  reduces  to  2.5  usee,  but  severe  loading  on  the  control  proce.ssor 
is  forced.  This  load  appears  to  be  greater  than  can  be  handled  by  even  a fast  processor. 

Without  special  hardware  the  UART,  approach  provides  a high  load  on  the  control  proces.sor.  This 
load  can  be  reduced  by  implementing  a scheme  in  which  the  hardware  filters  all  “sync”  characters 
and  allows  only  essential  control  characters  to  reach  the  processor  interface. 

To  find  a matrix  control  speed  which  satisfies  the  signal  processing  requirements  requires  investiga- 
tion on  a case-by-case  basis. 

Serial  Bus  — The  Serial  Bus  has  a turn-around  time  at  best  of  237  8 usee  assuming  33,640  control 
sequences  per  second  ard  eight  modules  in  the  .system.*  The  matrix  defined  allows  for  only 
1,462  control  sequences  per  second  or  a 5.4  ms  turn-around  time.  Neither  of  these  times  appear 
to  be  useable  m ' signal  proce.ssing  system.  It  .should  be  noted  that  in  the  10  channel  system  this 
problem  is  not  present  since  ail  connections  can  be  established  at  once. 

The  results  of  the  comparison  in  terms  of  Control  Requirements  .show  the  Paiallei  Bus  first.  The 
Serial  FDM/TDX  Bus,  and  the  .Matrix  do  not  appear  to  satisfy  signal  processing  requirements. 
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ARCHITECTURE  SELECTION  FOR  SWITCHING  SYSTEMS 


i.  Summary 


A functional  layout  fur  message  switching  for  each  of  the  three  architectures  has  been  formulated  based  on 
the  descriptions  in  Appendix  A.  The  following  general  assumptions  have  been  made  to  allow  a valid  com- 
parison among  the  three.  The  functional  task  modules  necessary  in  the  message  switch  are  assumed  to  be 
designed  such  that  they  are  independent  of  their  interconnection.  Any  interconnection  dependencies  will 
be  resolved  in  the  module  interface  units,  i.e.,  BEU.  MID,  MIC  as  appropriate. 

The  items  that  must  be  evaluated  in  the  selection  of  one  of  the  three  architectures  that  are  unique  to 
their  respective  architecture  are  listed  below; 


Architecture 

Interface  Module 

Interconnect  Scheme 

System  Control 

Serial 

MIU 

Coax  bus  prior 

Tech  Control,  Repeaters,  and 
Process  Control 

Matrix 

MIC 

Matrix  hardware 

.System  Control 

Parallel  Bus 

BEU 

Thirty  four  parallel 
lines 

Timing  and  Control 

Table  H-1  summarizes  the  results  of  these  analyses  in  raw  score  form.  Weighted  score  and  best  worst  com- 
parisons are  given  in  figures  H-1  and  H-2,  respectively. 

11.  Architecture  Comparison  by  Cost 

1.  Required  Hardware  .'Software 

A.  Needed  to  support  minimum  configuration.  The  minimum  configuration  for  a switching  system 
would  be  one  CPU,  one  main  memory,  one  line  or  trunk  handler,  and  whatever  support  hard- 
ware and  software  that  is  required  by  the  particular  architecture.  The  minimum  configuration 
considered  to  be  of  significant  practical  interest,  however,  includes  one  CPU.  one  main  memory, 
three  line  handlers,  and  one  trunk  handler.  It  is  support  for  this  configuration  that  is  considered 
below.. 

Parallel  Bus 

6 BEUs  (2  4"  X 1"  circuit  cards  each) 
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Table  H-1. 
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U.  RELIABILITY 
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Table  H-1  jConU. 


CHOICE 


WEIGHTED  SCORES 


BEST  MID.  WORST  MATRIX  BUS  SERIAL 


II.  RELIABILITY  (Cont.) 


RELIABILITY  TOTAL 


III.  PERFORMANCE 


PERFORMANCE 

TOTAL 


Matrix 


7 MIC’s  (3  4"  X 7"  circuit  boards/500>-1200  words  of  microcode  each) 

I Matrix  switch  and  controller  (3  4"  x 7”  circuit  boards/200-800  words  of  microcode) 


Serial  Bus 


7 MIU’s  (6  4"  X 7"  circuit  boards  each) 

2 repeaters  (2  4"  x 7"  circuit  boards  each) 

14  taps 

1 technical  and  process  controller  (1  minicomputer/8K— 20K  lines  of  assembly  language) 


B.  Needed  to  support  each  additional  module 

Parallel  Bus  - To  add  one  line  handler  or  trunk  handler  to  the  system  requires  the  addition  of 
one  BEU  (2  - 4 x 7"  circuit  boards).  Slight  additions  must  be  made  to  the  CPU  software  to 
extend  such  things  as  routing  tables,  interrupt  handlers,  etc.  This  addition  of  modules  can  go  on 
almost  indefinitely  until  traffic  causes  congestion  on  the  bus,  or  the  CPU  or  memory  become 
overloaded.  Memory  size  can  be  increased  with  no  other  additional  hardware  and  only  a minor 
change  to  the  memory  allocation  routines  in  the  CPU.  Alternatively,  an  additional  memory 
module  and  BEU  can  be  attached  to  the  bus.  ITiis  approach  also  increases  available  memory 
bandwidth  if  the  bus  bandwidth  exceeds  that  of  a single  memory  module. 
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Adding  a CPU  to  the  system  requires  an  additional  BEU.  Software  in  the  original  CPU  may  be 
repartitioned  or  duplicated.  Assuming  that  the  original  software  was  modular  leads  to  the  con- 
clusion that  repartitioning  is  easy.  If  duplicate  code  is  to  be  used,  the  original  design  must  have 
provided  for  .such  things  as  shared  access  to  tables  and  dynamic  task  queing. 

Matrix  - To  add  a line  handler  to  the  system  requires  the  addition  of  an  MIC  module 
(3  - 4 X 7"  circuit  boards)  provided  the  matrix  switch  was  designed  for  the  additional  paths. 

This  addition  can  continue  only  as  long  as  spare  paths,  which  were  originally  designed  in,  are 
available.  Multiplexing  hardware  could  have  been  designed  in  to  allow  fewer  paths  to  handle 
more  modules.  This  would  have  improved  expandibility  but  would  require  more  hardware 
and  would  have  destroyed  the  non-blocking  features  of  the  matrix.  Expandibility  could  also  be 
improved  by  utilizing  a network  of  sub-matrices  to  which  other  sub-matrix  switches  could  be 
added. 

If  software  is  handled  properly  within  the  MIC  during  original  design,  software  modifications 
can  be  minimum  or  none  at  all  when  MICs  are  added.  Software  in  the  matrix  controller  would 
be  written  to  support  a fully  implemented  matrix  and  would  require  no  modification.  Addition 
of  CPU’s  and  memory  to  this  system  is  subject  to  the  same  considerations  as  for  the  parallel  bus. 

Serial  Bus  - To  add  a line  handler  to  the  system  requires  the  addition  of  an  MIU,  two  bus  taps, 
and  modifications  to  the  control  software.  Technical  control  must  be  informed  of  the  character- 
istics of  each  new  hardware  module  and  process  control  must  be  informed  of  the  configuration 
and  procedures  for  all  new  system  tasks.  Adding  a CPU  to  this  system  is  not  significantly 
different  than  adding  a line  handler  since  process  control  takes  care  of  task  scheduling.  Memory' 
may  be  added  with  or  without  additional  MIU’s  and  taps. 

2.  Flexibility 

The  rationale  for  the  selection  of  the  architecture  hv<ed  on  flexibility  appears  to  be  identical  whether 
the  application  is  for  signal  processing  or  for  message  switching. 

A.  How  well  are  widely  varying  performance  requirements  bandied? 

Bus  - Addition  of  new  modules  limited  only  by  bandwidtli  and  addressability.  (Bus  buffers 
must  be  added  for  groups  of  100  modules. ) 

Matrix  - Addition  of  new  modules  limited  by  bandwidth  and  severely  limited  by  number  of 
available  ports.  Tlie  limited  number  of  connections  makes  it  undesirable  to  utilize  a port  for  a 
low  speed  device,  but  multiplexing  multiple  low  speed  devices  onto  a single  port  causes  other 
complications. 

Serial  - Addition  of  new  modules  limited  only  by  bandwidth  (addre$.sing  capability  is  essentially 
infinite  for  switching). 
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B.  Is  it  easy  to  go  from  the  general  to  the  specific? 
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Bus  - A heirarchy  of  busses  may  be  easily  defined.  This  can  be  ased  to  increase  bandwidth 
and  addressability. 

Matrix  - Assuming  “smarts”  are  distributed  in  using  modules,  this  is  not  too  difficult.  The 
design  process  is  aided  by  concunent  applications  design.  A beirarchy  of  matrice-  and  sub- 
matrices can  be  defined  to  extend  addressability. 

Serial  - No.  A good  understanding  of  Technical  and  Proce.ss  Control  is  necessary  to  achieve 
efficient  interaction  of  the  module  with  them.  The  present  description  of  the  software  used  to 
implement  technical  and  proce.ss  control  *s  sketchy  at  best,  but  indications  are  that  it  is  very 
general  and  very  complex. 

C.  Is  the  speciHc  still  general  relative  to  the  class  of  problems? 

Bus  - Yes,  if  a heirarchy  is  used.  Also,  most  microprocessors  use  an  internal  bus  structure.  This 
says  that  one  may  proceed  from  general  to  specific  all  the  way  down  to  this  level.  Note  that  in 
doing  this  the  details  of  control  of  busses  at  the  different  levels  may  be  different.  This  increases 
the  burden  of  documentation  but  allows  existing  modules  which  use  different  control  mech- 
anisms to  be  incorporated  into  a system.  It  also  allows  a “new  and  improved”  module  which 
uses  a different  control  mechanism  to  be  incorporated  into  an  existing  system. 

< 

Matrix  - To  a limited  extent.  This  feat'jre  can  be  strengthened  by  the  use  of:  matrix  submatrix 
techniques,  programmable  modules,  and  general  purpose  I/O  routines  in  the  MICs. 

Serial  - No.  This  system  seems  to  go  from  the  general  solution  of  all  the-  problems  in  the  universe 
to  the  specific  solution  of  a particular  case  in  one  fell  swoop. 

3.  Adaptable  Within  a Configuration 
A.  Growth  (see  also  section  2A) 

This  section  will  address  only  the  addition  of  line  handlers  to  the  system.  If  the  original  design 
provided  for  increases  in  the  size  of  memory  or  number  of  CPU's,  then  the  cost  to  support  such 
growth  will  be  either  negligable  or  roui^ly  equivalent  to  that  for  adding  a line  handler.  If  such 
provisions  were  not  made  in  the  original  design,  then  growth  in  these  areas  is  not  grov/th  “within 
the  configuration.” 

Bus  - Can  be  expanded  by  adding  a BEU  for  each  line  handler  and  by  adding  the  addresses  of 
the  added  devices  to  the  appropriate  tables  in  the  CPU  software. 
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Matrix  - Can  be  expanded  by  adding  an  MIC  for  each  line  handler,  if  unused  matrix  ports  were 
defined  in  the  original  configuration.  Once  the  ports  are  all  used,  growth  within  the  configura- 
tion ceases.  Since  the  size  of  the  matrix  is  known  at  design  time,  the  CPU  software  would 
probably  be  written  to  include  all  possible  device  addresses  in  its  original  tables.  Therefore,  no 
software  changes  would  be  needed  for  growth  within  the  configuration. 

Serial  - Can  be  expanded  by  adding  an  MIU  and  two  taps  for  each  line  handler.  CPU  tables 
must  be  updated  and  process  and  technical  control  must  be  informed  of  the  existance  of  the 
new  devices. 

B.  How  can  field  changes  be  tested  and  implemented? 

Bus  - Field  changes  to  the  hardware  are  reasonably  easy  as  long  as  the  mechanical  design  provides 
easy  access  to  the  bus.  When  a new  module  is  added,  a malfunction  or  design  error  in  the  new 
module  may  make  the  entire  system  inoperative.  This  risk  is  reduced  by  using  a standard  circuit 
for  BEU.  Field  changes  to  the  software  carry  a similar  risk  of  tying  up  the  bus. 

Matrix  - Addition  of  a hardware  module  is  easy  if  a port  is  available.  The  addition  of  software 
modules  or  replacement  of  a hardware  module  is  also  easy.  The  risk  involved  in  such  changes  is 
very  low  since  the  matrix  provides  isolation  between  its  ports. 

Serial  - Field  changes  are  relatively  easy.  Sy.stem  down  time  for  the  addition  of  a hardware 
module  is  dependent  on  the  ease  of  installing  a tap.  Since  the  taps  provide  isolation  from  the 
serial  line  and  the  operation  of  the  MIU’s  can  be  verified  prior  to  installation,  additional  down 
time  is  unlikely.  A hardware/software  module  can  be  replaced  with  the  system  only  losing  the 
ability  to  perform  tasks  which  require  that  module. 

C.  Can  the  design  accommodate  technology  change  in  signaling  techniques,  filtering  techniques, 
etc.?  (What  is  the  probability  of  such  change?) 

Bus  - Yes  - Burden  of  change  is  on  the  module. 

Matrix  - Yes  - Burden  of  change  is  on  the  module. 

Serial  - Most  technology  changes  would  affect  only  individual  modules.  Advances  in  the  area  of 
fiberoptics  could  make  the  serial  communication  technique  much  more  attractive. 
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4.  Ease  of  Design 

The  message  switching  selection  rationale  is  identical  to  that  for  signal  processing. 

A.  What  hardware/software  exists  that  is  similar  or  identical  to  the  required  modules? 

Bus  - Much  hardware  exists  which  is  very  similar  to  that  required.  The  BED  functions  need  only 
to  be  repackaged.  Much  software  for  bus-oriented  machines  also  exists. 

Matrix  - Matrix  systems  are  not  common,  but  they  are  relatively  easy  to  work  with  at  the 
conceptual  level. 

I 

Serial  - Similar  hardware  is  not  well  known.  Extensive  executive  software  is  required. 

B.  Can  “standard”  components/ianguages  be  used? 

Bus  - Yes.  Bus  interfaces  which  are  implemented  with  small  scale  integrated  circuits  already 

exist.  Medium  scale  integrated  circuits  which  now  exist  may  be  used  to  improve  this  interface.  i 

The  bus  architecture  has  no  specialized  language  requirements. 

I 

i 

Matrix  - Yes.  The  matrix  controller  and  interface  units  are  implemented  with  microprocessors. 

The  language  used  in  this  system  must  be  able  to  generate  efficient  microcode. 

i 

Serial  - Yes.  This  system  uses  a mixture  of  standard  logic  elements,  standard  CATV  elements,  j 

and  standard  minicomputers.  To  improve  cost,  custom  large  scale  integration  should  be  con-  j 

sidered  for  the  interface  units.  This  architecture  has  a stronger  requirement  for  a job  control  | 

or  process  control  language  than  the  other  two  do.  I 

C.  Are  boUi  the  hardware  and  software  natural  to  use  or  does  one  have  to  continually  be  “clever”? 

I 

Bus  - Better  than  average.  Cleverness  is  required  only  if  bus  bandwidth  and/or  software  execu- 
tion time  limits  are  approached.  The  hardware  module  interface  is  extremely  simple.  A 

similarly  simple  software  module  interface  can  be  used.  The  module  designer/programmer  needs  j 

to  know  very  little  about  the  rest  of  the  system.  As  is  always  the  case,  it  is  highly  desirable  that  j 

at  least  one  person  on  the  project  understand  the  entire  system  to  insure  efficient  operation. 

Matrix  - Average  design  difficulty.  Module  design  requires  some  knowledge  of  the  system. 

Serial  - If  the  latency  in  moving  data  and  getting  a positive  response  can  be  tolerated,  the 

system  is  reasonably  natural  to  use.  Good  executive  software  is  the  key  to  this  factor.  Module  j 

design  requires  extensive  knowledge  of  the  system  including  executive  software.  I 
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D.  Can  it  be  tested  simply? 


1.  Can  it  be  tested  incrementally? 

2.  Can  it  be  easily  prototyped  and/or  simulated? 

Bus  - 1.  Yes 
-2.  Yes 

Matrix  - 1.  Yes.  Minimal  test  configuration  is  somewhat  large. 

- 2.  Probably  average. 

Serial  - 1.  Yes.  Minimal  test  conHguration  would  be  technical  and  process  control  and  one  or 
two  test  modules.  This  >s  still  a fairly  large  collection  of  hardware  and  software. 
Specialized  executive  test  software  would  be  very  helpful  if  not  essential. 

- 2.  Coarse  simulation  would  be  fairly  easy.  Prototyping  would  be  a fairly  major  effort. 


5.  Ease  of  Documentation 

A.  Common  Interface  for  software  and/or  hardware  modules? 


Bus  - Can  Be.  As  an  example,  a vectored  interrupt  can  be  processed  by  a dedicated  hardware 
module  or  by  a specific  software  module  within  a hardware  module. 

Matrix  - A common  hardware  interface  exists  between  the  matrix  switch  and  the  MIC’s.  The 
MIC’s  are  microcoded  to  meet  the  needs  of  the  individual  module.  The  module  interface  is 
therefore  less  standardized.  Software  interfaces  to  the  line  handlers  are  standardized,  but  it  is 
not  readily  apparent  that  the  hardware  and  software  modules  could  be  easily  interchanged. 

Serial  - A common  hardware  interface  exists  up  to  a point.  Beyond  this  point,  the  “flexibility” 
exists  to  tailor  the  interface  to  the  module.  It  is  presumed  that  a similar  situation  would  exist 
with  the  executive  software.  It  is  not  readily  apparent  that  the  hardware  and  software  module.*; 
could  be  easily  interchanged. 

B.  Degree  of  self-documentation  of  the  hardware/software 

Parallel  Bus  - TTie  BEU’s  common  boards  are  documented  once  and  then  used  by  all  modules. 
Each  unique  board  must  be  documented.  The  BEU  mechanical  packaging  can  be  documented 
once  for  all  BEU’s. 

Matrix  - The  MIC  common  boards  are  documented  once  for  all  MIC’s.  The  MIC  mechanical 
packaging  can  also  be  documented  once  for  all  MIC’s.  The  system  control  module  must  have 
documentation  for  each  of  its  circuit  boards  and  its  mechanical  packaging.  Software  for  the 
system  control  module  and  MIC’s  must  be  documented.  The  software  for  the  individual  line 
handlers  is  identical  or  nearly  identical. 
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Serial  Bus  - The  MIU  common  boards  and  the  MIU  mechanical  packaging  are  documented  once 
for  all  Mill's.  The  technical  and  process  control  minicomputer  and  associated  software  must 
be  documented  separately.  The  bus  repeater  and  taps  can  be  documented  once  each  and 
repeated  for  all  others. 

Did  the  original  design  light  the  way  for  future  changes?  This  is  necessary  because  personnel 
will  usually  be  different  between  an  initial  design  and  the  redesign  event. 

Bus  - Better  than  average  because  of  existing  documentation  and  simplicity  of  architecture. 

Matrix  - Yes,  if  reasonable  documentation  support  is  maintained. 

Serial  - Can,  but  complexity  of  the  system  would  require  the  original  designer  to  be  very  con- 
scientious in  his  documentation  effort,  particularly  in  the  area  of  software  documentation. 
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6.  Manufacturability 

A.  State  of  the  Art 

Parallel  Bus  - The  parallel  bus  does  not  utilize  new  techniques  or  components.  The  simplicity 
of  the  Bi^U’s  and  the  low  quantity  of  circuit  board  types  make  it  easy  to  manufacture.  The 
state-of-the-art  could  be  improved  by  high  usage  of  LSI’s.  All  parts  are  readily  available  off-the-shelf. 

Matrix  - The  matrix  also  is  not  pushing  the  state-of-the-art.  The  elements  that  make  up  the 
matrix  and  its  controller  are  bencfitting  from  increased  use  of  LSI.  All  components  are  off-the- 
shelf.  Manufacturability  is  not  as  easy  as  the  parallel  bus  because  of  the  increased  circuit  board 
types  and  modules. 

Serial  Bus  - The  serial  bus  is  probably  closer  to  the  state-of-the-art  than  any  of  the  three  archi- 
tectures. If  nber-optic  buses  were  utilized,  the  architecture  would  be  pushing  the  state-of-the- 
art.  Manufacturability  is  more  difricult  than  the  other  two  architectures  because  its  high 
quantity  of  non-identical  modules  and  circuit  board  types. 

B.  Does  the  depth  of  the  logic  require  long  test  sequences? 

Bus  - Test  sequences  are  determined  by  modules.  Almost  no  length  is  added  to  the  test 
sequences  as  a result  of  the  parallel  bus  architecture. 

Matrix  - Test  may  be  complex  - more  so  that  a parallel  structure  at  least.  The  larger  amount  of 
software  required  may  be  a benefit  in  larger  production  runs. 

Serial  - Serial  interfaces  tend  to  genente  long  test  sequences. 
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C.  Does  “cleverness”  of  the  design  require  high-level  test  technicians? 

Bus  - Not  usually.  Certain  types  of  faihu'es  on  the  bus  are  difficult  to  isolate.  Data  transactions 
on  the  bus  can  be  difficult  to  ob.serve.  The  use  of  logic  state  analyzers  significantly  reduces 
these  problems. 

Matrix  ~ Normal  test  personnel  requirements  are  adequate. 

Serial  - Cleverness  as  described  in  4C  may  require  some  high  level  test  technicians.  The  mix- 
ture of  logic  type  components  and  CATV  type  components  found  in  this  system  will  cause 
some  additional  difficulties. 

D.  Is  it  machine  diagnosable?  (Machine  diagnosis  may  reduce  but  not  eliminate  the  impact  of  the 
above  two  items.) 

Bus  - Machine  diagnosis  of  module  failures  is  possible.  Machine  diagnosis  of  bus  failures  is  diffi- 
cult and  requires  special  provisions  in  the  hardware  to  isolate  such  failures. 

Matrix  - Machine  diagnosis  of  module  failures  is  possible.  Perhaps  trouble  at  the  module  inter- 
face (and  internal/  leve>  would  require  manual  intervention.  Monitoring  of  control  line  protocol 
and  data  line  activity  is  “built  in”. 

Serial  - Machine  diagnosis  of  module  failures  is  possible.  In  fact,  some  such  features  are 
“built  in”  to  the  system.  Failures  in  the  transmission  medium  should  be  easy  to  isolate 
manually.  Failures  in  technical  control  could  be  difficult  to  find  unless  an  independent  console 
is  attached  directly  to  the  minicomputer  that  provides  the  centralized  portion  of  this  function. 
Such  a console  and  possible  additional  I/O  devices  would  allow  extensive  self-test  routines  to 
be  implemented. 

E.  Can  design  phase  tests  be  used  to  partially  or  wholly  satisfy  production  test  requirements? 

Bus  - Very  little  testing  is  requited  beyond  the  test  of  the  individual  modules  A system  level 
“exerciser”  type  of  diagnostic  should  be  easy  to  write  for  this  .system. 

Matrix  - Yes.  Design  and  production  tests  require  module  simulation.  This  is  a design  time 
requirement  but  is  transfetable  to  production. 

Serial  - Due  to  the  complexity  of  the  system,  production  testing  will  probably  need  to  be  much 
more  extensive  than  that  used  in  the  design  phase. 
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7.  Maintainability 

Thp  message  switching  selection  rationale  for  maintainability  is  identical  to  that  for  signal  processing. 

A.  Can  fault  isolation  be  easily  achieved?  (Busses  make  this  difficult;  also  relative  addressing  of 
any  kind,  virtual  machines,  and  any  kind  of  multiple.xing  is  le.ss  than  optimum.) 

Bus  ~ Faults  v/ithin  modules  that  don’t  place  a fault  on  the  bus  itself  are  ea.sy  to  isolate.  Faults 
on  the  bus  can  be  veiy  difficult  to  Isolate. 

Matrix  - Fault  isolation  will  be  very  good  (rapid)  to  circuit-related  (i.e.,  channel)  failures. 
Control  switch  functions  would  be  only  average  unless  a “diagno.stic”  module  were  included 
in  the  system. 

Serial  - Most  faults  within  modules  are  easy  to  isolate.  This  .system  makes  it  very  unlikely  for  a 
module  to  place  a fault  on  the  serial  bus.  Most  failures  of  amplifiers  or  repeaters  can  be  quickly 
isolated  from  observing  loss  of  signal  or  data.  Transmission  line  failure  can  be  easily  isolated  to 
a particular  line  segment.  Failures  in  process  and  technical  control  may  be  difficult  but  most  of 
these  could  be  isolated  with  appropriate  self-diagnostic  programs. 

B.  Can  test  facilities  be  built  in  naturally? 

Bus  - Yes.  A timeout  for  bus  transactions  is  built  into  the  control  module.  With  medium  scale 
integrated  circuits  that  are  now  available,  parity  generation  and  checking  can  be  added  with  no 
cost  increase. 

Matrix  - Yes.  All  control  and  data  lines  are  full  duplex  with  the  return  path  being  used  for 
control  response  and  error  control.  Sync  characters  are  transmitted  constantly  on  idle  control 
and  data  lines.  For  every*  chR^'act^jr  transmitted  a character  is  also  returned.  The  matrix  con- 
tn.iiler  constantly  monotors  operations  for  validity. 

Sena)  > Yes.  Some  arc  included  in  the  original  dermitiun  of  this  architecture. 

C.  Cabling,  connections,  etc.  Do  these  force  unnatural  mechanical  designs  which  are  hard  to 
maintain? 

Bus  > The  large  number  of  wires  in  the  parallel  interface  can  cause  difficulties. 

Matrix  - Cabling  is  better  than  average.  The  serial  nature  of  the  communicaticn,-;.  and  the 
lower  data  rate  (i.e.,  data  rate  is  a per-channel  phenomena  - not  a total)  yield  simpler 
connections. 

Serial  - Cabling  U very  simple.  Special  attention  must  be  paid  to  the  coax  connectors. 
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D.  Can  the  mechanical  design  be  transferred  easily?  (This  is  a mea:  ■ “«  of  the  simplicity  of 
connection.) 

Bus  ' Yes,  but  the  large  number  of  wires  can  cause  some  problems. 

Matrix  - Mechanical  design  for  expandability  is  easy  only  within  limits.  Extra  channels  may 
easily  be  added  but  the  basic  size  of  the  switch  cannot  be  changed  in  existing  equipment.  New 
designs  could  accommodate  larger  switches  without  much  design  time. 

Serial  - Yes.  Special  attention  must  be  paid  to  the  coax  connectors. 

HI.  Reliability  Comparison 


MTBF 

MTBF  depends  primarily  on  the  types  of  parts  used,  the  quantity  of  various  types  of  parts,  and  the 
number  of  connections.  The  interconnected  task  modules  are  not  included  in  an  MTBF  evaluation 
because  these  modules  are  constant  regardless  of  the  architecture  selected.  Only  the  interface 
modules,  the  interconnections  between  the  interface  modules,  and  the  method  of  technical  and 
system  control,  are  unique  to  the  architectures  and  are  considered  in  the  MTBF  selection. 

Interface  Modules  — The  MIU  (Serial)  and  the  MIC  (Matrix)  interfaces  are  about  equal  in  types  and 
quamtities  of  hardware.  The  BEU  is  much  less  complex  than  the  others  and  has  less  hardware. 

Each  MIC  (Matrix)  module  contains  a microprocessor  for  path  control,  and  therefore  is  rated  poor 
in  MTBF. 


Interconnect  Scheme  — The  interconnection  of  the  serial  bus  is  two  coax  connectors  per  MIU  which 
is  the  fewest  quantity  of  connectors  of  the  three.  The  Matrix  requires  an  interconnect  between  each 
MIC  and  the  matrix  sw.tch  which  is  roughly  equivalent  to  the  serial  bus  quantity;  however,  the 
matrix  h.as  the  additional  connections  of  the  matrix  switch,  itself.  The  parallel  bus  contains  34  wires, 
requiring  34  connections  to  each  BEU;  therefore  sho.,ld  have  the  worst  reliability  of  the  three 
architectures  as  far  as  interconnects  are  concerned. 


Technical  and  System  Control  — Technical  and  system  control,  including  timing,  is  distributed  within 
the  task  modules  in  the  parallel  bus  architecture.  Each  line  handler  module  does  its  own  transferring 
and  fetching  of  data  via  the  BEU.  The  BEU  is  completely  asynchronous.  This  technique  requires 
less  hardware  in  the  BEU  than  would  be  required  in  the  serial  bus  MIU  or  the  matrix  MIC. 

It  is  the  responsibility  of  the  MIC  in  the  matrix  system  to  request  connection  to  a specific  port  or 
to  request  disconnection  ftrom  the  current  port.  The  actual  establishment  of  connections  is  done  by 
the  matrix  switch  controller. 


I i 

f 


The  serial  bus  MIU  contains  hardware  for  keeping  track  of  time  slot  and  address  assignments,  as  •/.  eii 
as  bus  synchronization.  Further  bus  synchronization  hardware  is  present  in  the  bus  repeater.  This 
system  has  a minicomputer  dedicated  to  the  overall  function  of  technical  and  process  control. 


2.  Single  Point  Failure 

Interconnect  — Every  wire  connection  is  a potential  single-point  failure.  Since  the  interconnect  for 
the  serial  bus  is  two  coax  connections  to  each  MIU,  it  wil*  have  the  fewest  single  point  failures. 


The  matrix  has  a group  of  control  wires  in  addition  to  the  data  line  that  connects  from  each  MIC  to 
the  matrix  switch.  Each  of  these  connections  represent  failure  points,  but  these  are  not  necessarily 
complete  system  failures. 


Since  the  parallel  bui  contains  34  wires  that  connect  to  every  BEU,  it  has  the  highest  number  of 
points  of  failure.  However,  the  potential  for  thes-.  particular  failures  is  not  as  high  as  those 
described  for  the  serial  interconnections,  because  of  the  lower  reliability  of  coax  connectors. 


Interface  Modules  — 'fhe  interface  modules  in  order  of  complexity  and  part  count  are;  MIU  (Serial), 
MIC  (Matrix),  and  BEU  (Parallel).  Therefore,  the  potential  fur  single  point  failure  is  in  the  same 
order. 


Technical  and  System  Control  - The  serial  bus  and  the  matrix  contain  more  hardware  and  software 
modules  for  system  control  than  does  the  parallel  bus;  i.e.,  the  serial  bus  requires  the  bus  repeater 
and  technical  control  minicomputer  for  technical  control  of  the  bus.  The  matrix  requires  control 
and  record  keeping  of  the  interconnect  paths  through  the  matrix  switch.  These  additional  modules 
give  additional  failure  points.  Therefore,  the  potential  for  single  point  failure  due  to  control  modules, 
highest  to  least,  is:  serial,  matrix,  parailel. 


3.  Types  of  Failure  ; lodes 

M in  the  signal  processing  section  (Appendix  G).  the  failure  modes  attributable  to  the  architecture 
«re  the  same  for  all  three  architectures:  Failure  to  release  a connection,  failure  to  make  a connection, 
making  wrong  connection,  etc.  The  mechanisms  that  create  the  failure  modes  are  different,  with 
di.fferent  failure  rates,  but  the  modes  themselves  remain  the  same.  The  detectability  of  some  of  the 
modes  '$  better  in  the  Matrix  ;md  Serial  systems.  The  Matrix  system  has  good  detectability  because 
of  the  one-to-one  connection  path.  The  Serial  system  has  built  in  monitoring  of  time  slot  and 
identir.cation  assignments. 


Technology  Limits 

a.  Timing  Constraints  - None  of  the  architectures  appear  to  be  pushing  the  technology  limits.  The 
serial  bus,  because  of  its  high  speed,  bit-sync,  slot-sync,  and  frame-sync  requirements  has  the 
must  -severe  timing  co;.straints. 
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b.  Envifonmental  Sensitivity  - The  serial  bus,  because  of  its  timing  and  circuit  complexity,  is  most 
likely  to  be  influenced  by  environmental  extremes. 


5.  Maturity  of  Technology 

Each  of  the  three  architectures  can  be  realized  with  today’s  technology.  The  paraliel  bus  architecture 
seems  to  be  the  best  understood  and  most  used;  therefore,  it  has  the  largest  family  of  specialized 
components.  The  Serial  Bus  system  is  not  widely  used  in  localized  switching  processors. 

IV.  Performance  Comparison 

1.  Data  Processing  Capability 

Once  the  transmission  path  has  been  established  (data  transfer  only),  the  matrix  architecture  and 
the  serial  bus  at  .-  very  close  in  data  transfer  rate  with  the  parallel  bus  being  slowest. 

The  matrix  is  the  fastest  of  the  three  architectures  because  of  itf  dedicated  transmission  paths. 

Each  device  on  the  serial  bus  has  its  own  bandwidth  assigned;  i.e.,  it  has  its  own  time  slot(s) 
assigned.  In  a sense,  these  time  slots  can  be  considered  parallel  paths  in  that  they  are  assigned  and 
no  contention  for  a particular  assigned  slot  exists;  however,  there  is  a time  delay  involved  in 
utilizing  the  slots.  The  transfer  of  data  on  the  parallel  bus  architecture  must  be  considered  serial 
in  the  sense  that  only  one  device  at  a time  can  pass  data  on  the  bus. 

2.  Control  Overhead 

A.  Establishing  Interconnect  - The  matrix  architecttire  requires  more  overhead  in  establishing  the 
interconnects  which  partially  offsets  its  advantage  in  data  transfer.  The  serial  bus  requires  a 
lesser  amount  of  overhead  in  control  of  time  slots.  The  parallel  bus  has  minimal  overhead  since 
the  time  necessaiy  to  request  and  acquire  the  bus  is  overlapped  with  the  preceeding  data  transfer. 

B.  Protocol  - The  matrix  appears  to  require  more  protocol  between  processors  and  hardware 
blocks  in  establishing  transmission  paths  than  either  the  serial  bus  or  the  parallel  bus.  The 
serial  bus  and  parallel  bus  are  both  relatively  low  in  this  type  overhead. 

C.  System  Overhead  - The  serial  bus  is  very  high  in  overhead  bandwidth  for  maintaining  system 
and  bus  synchronization.  It  also  requires  a high  level  of  hardware  for  the  synchronization  and 
time  slot  counting.  The  parallel  bus  requires  less  control  overhead  than  any  of  the  other 
architectures,  having  transfer  information  contained  in  the  parallel  bus  with  the  data. 
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APPENDIX  1 


SIGNAL  PROCESSING  MODULES 


FUNCTIONAL  MODULES  OP  A SIGNAL  PROCESSING  SYSTEM 


The  following  sections  are  a group  of  modules  defined  for  a strawman  Signal  Processing  task  chosen  for 
use  in  the  architecture  simulation  phase  of  this  study.  This  communication  mode  is  an  encrypted,  band- 
spread,  antipodal,  phaseH:ontinuous  FSK  communication  mode  with  error  detection  and  correction. 

Signal  processing  starts  at  the  radio  receiver  IF  frequency  and  ends  with  error  corrected  characters.  Infor- 
mation flow  is  shown  in  Figure  I-l.  Message  blocking,  redundancy  te.sting,  message  routing,  etc.,  are  not 
contained  within  this  demodulator  but  are  left  for  the  next  higher  level  user  such  as  a switch  or  a radio 
operator.  The  signaling  rates  within  this  example  are  low,  but  it  is  felt  a good  understanding  of  the  charac- 
teristics of  the  architecture  modeled  can  be  gained  by  using  this  example. 

This  group  of  module  descriptions  is  necessarily  slanted  towards  the  parallel  architecture.  To  apply  these 
modules  to  the  Matrix  or  Serial  architecture  will  require  a slight  change  in  the  control  structure.  This  is 
caused  due  to  the  non-centralized  control  used  in  these  architectures.  Header  words  or  control  messages 
are  all  that  is  required  in  this  conversion. 

LI  TIMING  AND  EXECUTIVE  MODULE 

The  executive  control  of  this  signal  processing  example  takes  advantage  of  the  fixed  rate  processing 
inherent  in  Signal  Processing  Algorithms  by  pipelining  the  independent  operations.  Centralized  control 
simplifies  the  problem  of  controlling  the  modules  within  the  unit  and  is  implemented  by  allocating  tasks 
based  on  a central  timing  chain.  Allocation  of  all  buffers  within  the  unit  is  under  the  control  of  the 
executive  as  well  as  status  monitoring,  error  reporting  and  diagnostic  control.  Figure  1. 1-1  is  a block 
diagram  of  the  elements  within  this  module.  Operation  of  the  Task  Scheduling  is  initiated  by  an  interrupt 
from  the  central  timing  chain.  Tasks  are  then  passed  to  the  Task  Dispatcher  via  the  Task  Queue.  The 
Task  Dispatcher  is  responsible  for  initiating  and  monitoring  all  algorithms  within  the  signal  processor. 

/././  Module  HO 

TTiere  are  three  interfaces  to  this  module.  They  include:  a)  Direct  Timing  for  all  signals  higher  in  frequency 
than  normally  controlled  by  a processor  such  as  the  ,30  kHz  squarcwave  sent  to  the  IF  Pre-processing 
Module,  etc.,  b)  Vector  Interrupts  used  to  control  processing  modules,  and  r)  Programmed  interface  used 
to  collect  status  or  send  control  information. 

I 
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A.  Direct  Interface 

1.  Reference  Timing  - Frequency  reference  used  to  drive  the  central  timing  chains. 

2.  30  kHz  Squarewave  - Sent  to  the  iF  Pre-processing  Module. 

3.  1600  Hz  (or  20  kHz)  Squarewave  • Sent  to  the  KG. 
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Figurt*  M.  Infurmntion  Flow  Diagram  for  Signal  Processing  Modules. 


and  data  transfer. 

C.  Programmed  I/O  - The  programmed  I/O  is  used  to  send  buffer  addresses,  read  status,  or  any  other 
function  which  needs  to  be  accomplished  without  direct  module  communication. 


1.2  A/D  MODULE 


The  function  of  this  module  is  to  mix  quadrature  demodulator  timing  with  the  received  IF  to  extract  the 
baseband  signals  containing  the  information.  Figure  i.2-1  is  a block  diagram  of  the  IF  mixing  and  sampling 
section.  The  incoming  IF  is  mixed  with  the  quadrature  signals  of  the  demodulator,  filtered  to  limit  the 
bandwidth  of  the  signal  plus  noise,  and  sampled  at  the  Nyquist  rate  (or  hi^er).  The  sample  data  is  then 
passed  to  the  IF  Pre-processing  module  via  the  DMA  port  to  be  further  processed. 


1.2. 1 Signal  and  Timing  Control 
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A.  IF  - This  is  a 500  mv  RMS  (nominal)  signal  from  the  receiver.  IF  center 

frequency  is  7.6K.  (Note  - other  characteristics  such  as  impedance,  etc., 
will  not  be  included  but  can  be  found  in  the  receiver  manual.) 

B.  *AGC-  This  is  a +5V  signal  slowly  varying  as  a function  of  receive  signal  level. 

C.  *Depth  - This  is  a 0 to  +5V  signal.  Can  be  considered  approaching  DC  in  BW. 

D.  Local  Reference—  This  is  4 times  the  IF  frequency  (30  kHz)  and  is  divided  into  quadrature 

signals  within  the  module.  It  is  then  used  to  extract  baseband. 

E.  Sample  Time  — This  signal  initiates  the  A/D  samples  sequence.  It  occurs  at  least  4 times 

the  baseband  rate.  We  will  use  6400  in  this  case. 

1.2.2  But  Data  To  Matched  Filter  Module 


A. 


B. 


Sample  Data  - 9-bit,  2’s  compliment  numbers  sent  to  the  IF  Pre-processing  module.  They  occur  at 
the  baud  rate  and  are  sent  by  DMA. 

Status  - Sent  to  the  status  panel  at  the  baud  rate. 


1.3  IF  PRE-PROCESSING  MODULE 

The  function  of  this  module  is  to  reduce  the  signal  sampling  rate  of  the  data  received  from  the  A/D 
Module  to  that  of  the  matched  filter  input  rate.  The  data  is  placed  in  an  elastic  buffer  which  is  controlled 
by  the  sync  module  using  fine  sync  adjustments  to  track  doppier  or  to  correct  for  sync  mismatch. 


*Not  included  in  model. 
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1.3.1  inputs 

A.  A/D  samples  from  the  A/D  Module.  Received  via  the  DMA  channel  at  the  sample  rate.  Two  9 bit  2’s 
compliment  number  received  at  the  6400  Hz  sample  rate. 

B.  Fine  sync-corrections  received  at  the  sync  computation  rate.  Sent  by  the  Sync  Module  via  the  DMA 

port.  < 

C.  Control  - Two  vector  interrupts,  one  occurs  at  the  A/D  sample  rate  and  one  at  the  chip  baud  rate. 
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i.3.2  Outputs 

A.  Data  is  sent  via  the  DMA  channel  to  the  Matched  filter  module  at  the  baud  rate  (100  baud  to  1600 
baud).  Two  16  bit  2's  compliment  numbers  are  transferred  each  baud  period. 

B.  One  status  word  is  sent  to  the  status  panel  at  the  baud  rate. 
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1.4  MATCHED  HLTER  MODULE 

This  module  receives  sample  data  from  the  IF  pre-processing  module.  The  function  of  this  module  is  to 
multiply  the  sample  X and  Y data  with  a digital  1/2  sine-wave  representation  in  a transversal  filter,  sum 
the  results  and  output  the  results  to  the  next  module  which  is  the  Correlation  Module. 

Figure  1.4.1  is  a block  diagram  of  the  Match  Filter  Module.  In  this  implementation  the  sample  data  is 
separated  into  the  X and  Y substreams,  prefiltered  by  averaging  the  samples,  and  generating  subsample 
groups  with  eight  samples  used  for  each  chip  calculation.  The  indexed  buffer  shown  in  the  block  diagram 
is  used  for  fine  sync  and  doppler  tracking.  After  the  match  filter  operation  occurs  in  the  Transversal 
Filter,  the  chip  commutation  is  applied  giving  the  proper  sine-cosine  wei^ting  to  the  received  chip 
sequence.  Data  is  then  sent  by  the  DMA  port  to  the  correlators. 

1.4. 1 DMA  Pom 

A.  Sample  Input  Data 

Received  via  the  DMA  channel  in  a packed  format.  4 samples  of  X and  Y received  each  baud  time. 
Nine  bit  2’s  compliment  notation  representing  j;l0  volts  peak  to  peak.  Baud  time  in  this  case  occurs 
between  100  Hz  and  1600  Hi  rate. 

B.  Chip  Output  Data 

Output  at  the  computation  rate.  Data  is  transferred  via  the  DMA  channel  using  Uie  standard  DMA 
controls. 


1.4.2  Proptimmed  Port 


A.  Fine  Sync  • Thii  input  is  sent  by  the  sync  module  and  is  used  to  move  the  fine  sync  pointer  index, 

>1  from  the  current  position.  It  is  updated  once  each  sync  period. 

B.  Block  Unload  .\ddress  • This  is  a command  vrord  sent  by  the  Exec  specifying  the  address  to  transfer 
data  into.  This  command  is  sent  during  initialization  and  is  a 16  bit  word. 

C.  Status  • This  is  a sixteen  bit  word  sent  to  the  status  panel  at  the  chip  rate  to  determine  operational 
status  of  the  module. 

1.4.5  Timing 

All  timing  is  determined  by  the  Executive.  A vector  interrupt  is  used  to  inform  this  module  when  to 
initiate  an  output  transfer  and  calculate  the  new  chips. 

1.5  MULTI  WINDOW  CORRELATION  MODULE 

The  correlator  receives  chip  samples  from  the  Matched  Filter  Module,  multiplies  the  sample  with  key,  and 
sums  the  key /chip  resultant  over  the  defined  qrmbol  interval.  The  X and  Y chip  sums  are  delivered  to  the 
Symbol  Processing  Module  at  each  symbol  boundary  time.  Figure  1.5*1  is  a pictorial  diagram  of  this 
operation.  In  this  Signal  Processing  Module  only  one  key  per  chip  is  used  with  a ± sum  indicating  a logic 
one  or  zero.  The  multiple  windows  shown  are  used  to  resolve  time  ambiguities  in  the  signal  propogation 
path. 

/.  5.  / Mufti-  Window  CorrektioH  Modufe  Interfocet 

A.  DMA  - Two  DMA  functions  occur  within  this  module.  The  first  u the  Input  chip  sample  stream 
received  from  the  Matched  Filter  module  (See  the  MFM  description  for  the  data  format,  etc.). 

The  second  is  the  output  correlation  data  stream.  Ibis  output  occurs  at  the  symbol  rate  and  is  sent 
to  the  Symbol  Processing  module.  The  data  is  in  ttie  form  of  16*bit  2's  compliment  numbers, 
blocked  as  shown. 

B.  Interrupt  • Two  interrupt  Vectors  are  required  by  this  module.  The  first  occurs  at  the  baud  rate  and 
initiates  the  multiply  and  sum  operation.  The  second  occurs  at  the  symbol  rate  and  initiates  an  unload 
and  dear  operation. 

C.  Programmed  I/O 

1.  Key  Data  * Read  from  the  Key  Demultiplex  Module  at  the  baud  rate.  One  Key  is  required  at 
each  baud  time.  This  is  a 16  bit  word  of  ail  1 ’s  or  O's. 

2.  Unload  Address  > This  is  an  input  from  the  Executive  Module  occurring  during  initialization 
qrecifying  the  16  bit  address  to  move  symbol  data  to. 

3.  Status  • A 16  bit  status  word  is  sent  to  the  status  panel  at  the  symbol  rate. 
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1.6  KG  DEMUX  MODULE 
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The  fUnctiont  of  this  module  are  to: 

a)  Provide  KG  control;  i.e.,  ttari/stop  high  tpe^d  clocking,  start  lost  speed  clocking. 

b)  Real  time  input  and  run-up  calculation 

c)  Input  of  key  from  key  generator 

d)  Key  demultiplex 

e)  KG  failure  monitor 

IRis  module  interfaces  directly  with  a i^ey  Generator  (refer  to  Figure  1.6-1 ).  It  provides  clock  to  the  KG 
as  received  from  the  Timmg  module.  T‘te  clock  rate,  hi^  speed  or  low  speed,  is  provided  as  designated  by 
this  module. 

When  an  initialize  request  is  received,  real  time  is  read  from  the  cesium  standani  and  giant  step  increme’^tu 
are  calculated.  A request  for  hi^  speed  clock  is  made  to  the  timing  module  and  fed  to  the  KG.  When  run 
up  is  complete,  low  speed  clock  is  requested  and  fed  to  the  KG  or  the  next  minute  pulse. 

Raw  key  is  input,  demultiplexed  and  decrypted.  This  key  is  then  stored  as  a -1  or  a -rO,  and  provided  to 
the  correlators. 

The  KG  full  operate  line  is  also  monitored  and  stored  (>1  * KG  Failure),  and  sent  to  the  status  panel  at 
the  baud  rate. 

Since  the  KG  control  module  has  access  to  time,  a 24  hour  clock  (hours  and  minutes)  will  be  kept  and 
provided  on  request. 

1.7  SYMBOL  PROCESSING  MODULE 

Ihe  function  of  the  symbol  processing  module  is  to  reproduce  the  transmitted  symbol  from  the  correlated 
data  inputs.  This  is  accomplished  by  taking  the  dot  product  of  the  correlated  data  inputs  as  follows: 

■rr-(ojoj.«o;-9o“|^ 

Where  - Corraiatsd  components  of  the  current  bit 

(^,  8€^  ■ (Correlated  componente  of  the  previous  Int 
T ■■  Time  uncertainties 

Fig^ire  L7-1  is  a block  diagram  of  the  symbol  proceadng  module. 
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1.7.1  Inputs 
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a)  Input  Control 

Data  is  input  into  the  module  by  DMA  control.  The  DMA  input  was  initiated  by  the  Multi- 
Window  Correlator  Module.  The  interrupt  shown  is  timed  to  occur  after  the  DMA  input  is 
completed.  The  interrupt  signals  the  module  to  begin  its  processing  task. 

b)  Data  Format 

1)  Eight  16  bit  words  of  I (0^)  components  maximum  value  ==  (+)  6350 

2)  Eight  16  bit  words  of  Q (90*^)  components  maximum  value  ^ 6350 

3)  One  16  bit  word  where  bit  1 set  > frame  (phase)  bit 

c)  Input  Port 
DMA 

d)  Multiplex  Requirem«fits 
None 

e)  Timing 

1)  Rate:  1 7 words  every  bit  time 

2)  Sequence:  word  0 * frame  indication 

word  1-8  * I (0°)  component 
word  9-16  * Q (90°)  component 

f)  Addressing 
Single  address 

1.7.2  Output 

a)  Output  Control 

The  module  task  was  initiated  upon  a timed  interrupt  from  the  Timing  and  Executive  Module. 
The  data  generated  by  ihe  task  is  output  twice  by  DMA  control  to  first  the  Synchronization 
Module  and  then  the  Word  Processing  Module. 

Also  availalde  for  output  is  a 16  bit  status  word  of  the  module  condition.  Output  of  this  word 
it  controlled  by  programmed  I/O  by  the  Timing  and  Executive  Module. 

b)  Formats 

1)  DaU 

(a)  Eight  16  bit  words  each  consisting  of  values  between  -32767  to  -^32767. 

(b)  One  16  bit  word  where  bit  1 set  • frame  (phase)  bit. 

2)  Status  - 16  bit  word 

c)  Output  Ports 
Data:  DMA 
Status:  Program  I/O 


't'f  iismyi'’  WM 
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d)  Multiplex  RequiremenUt 
None 

e)  Timing 

1 ) Rate:  Nine  words  (data)  every  bit  time 

One  word  (status)  sent  to  the  status  panel  every  symbol  time 

2)  Sequence:  None 

f)  Addressing 

Two  addresses,  serial  data  transmit 
1.8  SYNC  MODULE 

The  function  of  the  Sync  Module  is  to  continually  search  for  synchronization  (presence  of  data  transmission) 
over  a pre-set  time  uncertainty  and  sync  time  period.  Figure  1.8-1  is  a simple  block  diagram  of  the  Sync 
Module.  The  data  over  which  synchronization  is  determined  is  the  bit  data  detected  by  the  symbol  proc- 
esnng  module.  The  absolute  values  are  accumulated  over  a predetermined  sync  period  (‘n*  bit  periods) 
across  a preset  window  (time  uncortainty).  A sync  threshold  is  calculated  each  sync  time  from  the  accumu- 
lated sync  data.  This  threshold  value  is  then  used  to  determine  if  data  is  being  transmitted  and  also  its 
location  within  the  time  uncertainty.  Fine  sync  calculation  is  made  after  »ync  has  been  detected  and  at 
the  end  of  each  block  period  thereafter  'intil  sync  is  lost. 

L8.1  Inputs 

a)  Input  Control 

Data  is  input  into  the  module  by  DMA  controlled  input.  The  DMA  is  initiated  and  controlled 
by  the  ^mboi  processing  module.  The  interrupt  (start  process)  shown  is  timed  to  occur  after 
the  DMA  input  is  completed. 

b)  Data  Format 

1 ) Ei^t  16  bit  words  each  consisting  of  values  between  -32767  to  -^32767. 

2)  One  16  bit  word  where  bit  1 set  « ftame  (phase)  bit. 

c)  Input  Port 
DMA 

d)  Multiplex  Requirements 
None 

e)  Timing 

1 ) Rate:  9 words  every  bit  time 

2)  Sequence:  Synchronize  to  a frame  (phase)  bit 

f)  Addressing 
Simple  address 


1.8.2  Output 


a)  Output  Control 

There  are  three  words  generated  for  output  by  the  module: 

1 ) Sync/No  Syne  Indication  with  Sync  Location 

2)  Fine  Synchronization  Correction  Direction 

3)  Module  Operation  Status 

These  output  words  are  accessed  (read)  by  the  Executive  Module  via  programmed  I/O.  The 
read  intervals  are  controlled  (.scheduled)  by  the  Executive  Module,  and  also  provided  to  the 
appropriate  modules  at  the  correct  time  intervals, 
h)  Data  Format 

1)  To  Word  Proce.ssing:  One  16  bit  word  identifying  sync  found  and  the  location  or  sync 
not  found. 

2)  To  Chip  Processing;  One  16  bit  word  with  fine  sync  correction  value  of  +1  or  -1., 

3)  Status:  One  16  bit  word 

c)  Output  Port 
Program  Control  I/O 

d)  Multiplex  Control 
None 

e)  Timing 

1 ) Rate:  Sync  Found /Lost  - 1 per  sync  period 

Fine  Sync  Correction  • 1 per  block 

2)  Sequence:  None 

f)  Addresses 

Three  • Sync  Word 

Correction  Word 
Status  Word 

1.9  WORD  PROCESSING  MODULE 

The  function  of  the  word  processing  module  is  to  reconstruct  the  code  word,  detect  and  correct  any  errors 
by  forced  erasure  schemes,  and  finally  to  extract  the  characters  for  output. 

Figure  1.9-1  is  a simple  block  of  the  Word  Processing  Module.  Identical  to  the  Sync  Module,  the  word 
processing  module  receives  the  bit  data  detected  and  processed  by  the  symbol  processing  module.  The 
maximum  data  stored  is  equivalent  to  the  sync  period  and  is  discarded  if  sync  is  not  obtained. 

However,  if  .sync  is  detected,  the  code  word  is  constructed  using  the  .sync  found  index  to  extract  the  bit 
data  from  the  bit  buffers.  A unique  parity  check  is  made  and  if  bad,  a forced  erasure  correction  is  made 
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Figure  1,9-1.  Word  Processing  Module. 


M8 


I 


using  the  associated  bit  magnitudes.  The  characters  are  extracted  from  the  code  word  and  stored  in  the 
output  buffer  for  output  to  the  device.  Appended  to  the  characters  is  one  of  the  following  generated 
message  (optional): 

i.)  No  Error  Detected 

b)  Errors  Detected  and  Corrected 

c)  Errors  Detected  and  Uncorrectable 

1.9  I Input 

a)  Input  Control 

Data  is  input  into  the  module  by  DMA  control,  initiated  and  controlled  by  the  symbol  proc- 
essing module.  The  interrupt  (start  process)  r^hown  is  timed  to  occur  after  the  DMA  input  is 
completed.  The  sync  data  word  is  input  just  prior  to  the  interrupt  by  the  Executive  Module 
by  programmed  I/O.  The  module  begins  processing  on  receipt  of  the  interrupt  and  sync 
notification. 

b)  Data  Format 

1)  Bit  Data 

(a)  Eight  16  bit  words  each  consisting  of  values  between  -32767  to  +32767 

(b)  One  16  bit  word  where  bit  1 set  = frame  (phase)  bit 

2)  Sync  Data 

One  16  bit  word  identifying  sync  found  and  the  location,  or  sync  not  found/lost. 

c)  Input  Port 

1)  BitDaU:  DMA 

2)  Sync  Data:  Program  Control  I/O 

d)  Multiplex  Control:  None 

e)  Timing 

1)  Rate:  Bit  Data  - 9 words  each  bit  time 

Sync  Data  - 1 word  each  sync  time 

2)  Sequence:  Synchronize  bit  data  to  frame  (phase)  bit 

f)  Addressing 
Two  Addresses 

19.2  Output 

a)  Output  Control 

‘n'  number  of  characters  are  buffered  by  the  word  processing  module,  and  are  output  by  DMA 
control  to  the  output  device  when  signaled  by  a 'data  output’  interrupt.  Module  status  is  also 
available  for  output.  This  status  word  is  output  via  programmed  I/O  by  the  Executive  Module. 

b)  Formats 

1)  Data:  ‘n’ number  of  16  bit  words,  three  5 bit  baudot  characters  »er  word. 

2)  Status:  16  bit  word 
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c)  Output  Port: 

1)  DaU:  DMA 

2)  Status:  Programmed  I/O 

d)  Multiplex  Control 
None 

e)  Timing 
None 

f)  Addressing 
Single  address 

I.I0  STATUS  PANFL  MODULE 

This  module  acts  as  a slave  to  the  other  modules  and  receives  a status  word  from  each,  updated  at  the  indi- 
vidual module  rates.  In  the  general  case  this  could  also  be  a control  panel  which  disable  timing  interrupts 
during  the  module  initialization  phase  or  could  be  scanned  by  the  executive  and  control  module  tit  some 
pre-determined  rate. 
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FUNCTIONAL  MODULES  OF  A MF.SSAGE  SWITCH 


The  identification  of  modular  elements  within  a message  switching  system  was  performed  as  a preparatory 
step  to  the  analysis  of  alter  native  modular  system  designs.  The  hardware  or  software  realization  of  these 
modules  and  their  roles  ,n  a total  system  are  described  below.  Functional  specifications  with  comments 
relative  to  application  to  a small  switch  follow  this  introductory  material. 

A message  switching  system  can  be  divided  up  into  various  functional  modules.  One  such  list  is  as  follows: 

A.  Line  Interface 

B.  Input  Service 

C.  Output  Service 

D.  Message  Storage 

E.  Message  Journaling 

F.  Validation 

G.  Routing 

H.  System  Control 

I.  Memory  Management 

J.  Eiror/Recovery 

K.  Initialization 

L.  Diagnostic/Test 


Aiiy  of  the  activities  of  a message  switch  can  be  found  under  one  or  moie  of  these  functions.  Also  there 
will  be  a hierarchical  relationship  that  exists  among  these  functions.  Exactly  how  each  function  fits  in  the 
system  hierarchy  will  depend  to  a large  extent  on  the  switch’s  implementation.  Because  this  relationship 
exists,  it  may  require  differen;  techniques  to  fully  describe  each  function. 

To  describe  the  previously  listed  functions,  a module  definition  specification  was  devised.  The  specification 
requires  each  module  to  be  defined  in  terms  of  its  input,  output,  and  transfer  operations.  For  some 
fiinctions  these  requirements  provide  an  easy  technique  for  describing  the  function  performed.  For 
example  the  input/output  service  modules  are  easily  described  in  this  format.  Using  this  specification  on 
functions  such  as  System  Control  proved  to  be  very  difficult.  This  difficulty  arises  from  the  fact  that 
System  Control  is  really  a group  of  independent  activities  that  in  combination  provide  contrr  ' r the 
system.  Thus,  the  modular  description  serves  as  a means  of  identification  and  assures  consideration  of 
each  function  during  the  design  process.  The  implementation  of  System  Control,  however,  will  be  as  part 
of  a system  executive  function. 


By  dividing  the  list  of  functions  into  two  inherently  different  classes,  each  class  can  be  described  in  a 
manner  suitable  to  it.  The  first  class  will  contain  those  functions  that  are  assigned  primarily  to  switching 
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messages.  The  second  class  will  contain  those  secondary  functions  that  allow  the  primary  functions  to 
communicate  with  each  other.  Thus,  the  secondary  functions  are  relatively  independent  of  “one  for  one” 
correspondence  with  the  number  of  system  lines.  A close  correspondence  of  this  type  does  exist  for  the 
pri’..iary  functions. 


The  primary  functions  will  be  hierarchically  lower  than  the  secondary  ones.  Dividing  the  initial  list,  the 
following  primary  functions,  with  the  steps  they  perform,  and  secondary  functions  are  obtained:.  (Refer 
to  Figures  J>1  and  J-2). 

PRIMARY  MODULES 

/.  Line  Interface 

A.  Input 

1.  Receive  modulated  signal 

2.  Qock  recovery 

3.  Demodulate  signal  to  NRZ 

4..  Synchronize  bits 

5.  Synchronize  characters 

6.  Generate  interrupt  to  Input  service 

B.  Output 

1.  Modulate  NRZ  signal 

2.  Outputs  modulated  signal  using  line  driver 
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II.  Input  Service 

A.  Fetches  character  from  Line  Interface 

B.  Checks  protocol 

C.  Translates  characters  (ii  needed) 

D.  Adds  header 

E.  Reformats  (if  needed) 

F.  Stores  message  in  main  memon  using  address  from  mailbox 

G.  Signals  complete  message  reception  in  mailbox 

H.  Initial  logging:  write  header  to  log  if  non-perishable 

III  Etlit/yalUation 

A.  Fetches  message  header  from  main  memory 

B.  Verifles  information  in  each  field 

C.  Crosscheck  information  between  Helds 

D.  Replaces  head«r  in  main  memory  if  modifled 

E.  Signals  results  of  edit/validation 
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Figure  J-1.  “Sirawman”  Message  Switch. 


IV.  Routing 

A.  Fetches  output  destinations  from  message  header 

B.  Determine  output  service  module  and  line  addresses  for  each  destination  and  construct  route 
control  words  (RCW)  for  each 

C Supervises  output  service  mailbox  protocol 

D.  Write  to  log  indicating  disposition  of  message  copy;  multiple  entries  for  multiple  addresses 

V Output  Service 

A.  Polls  its  mailbox  for  new  RCW 

B.  Fetches  message  from  main  memory 

C.  Translates  message  (if  needed) 

D.  Modifies  header  (if  needed) 

E.  Adds  line  protocol 

F.  Transfers  characters  to  Line  Interface  for  output 
SECONDARY  MODLLES 

I.  INITIALIZATION 

II.  MESSAGE  STORAGE 

III.  MEMORY  MANAGEMENT 

IV.  SYSTEM  CONTROL 

V.  ERROR/RECOVERY 

VI.  DIAGNOSTIC/TEST 

The  following  is  a description  of  each  primary  module  in  the  form  Input-Output-Transfer.  Only  a general 
description  of  the  secondary  modules  (except  the  Message  Storage  Module)  has  been  included. 

SWITCH  FUNCTION  MODULE;  LINE  INTERFACE  .MODULE.  TYPE:  PRIM  ARY 

/.  Generml 

The  Line  Interface  Module  provides  the  necessarj’  hardware  interface  for  the  line  handler  portion  of  the 
message  switch  with  the  subscriber  lines  or  loops.  It  performs  such  functions  as  modulation  and  demodu- 
lation of  signal  to  and  from  NRZ  signals,  clock  recovery  and  bit  synchronization,  line  driver  and  receiver 
terminations,  and  the  insertion  of  framing  signals  or  characters  as  required  by  the  subscriber.  .Multiple  lin< 
interface  modules  may  be  contained  within  a single  Line  Handier,  de(.wnding  on  the  speed  of  the  subscribers 
being  serviced.  A Line  Handler  contains  a single  procevsor  for  s«'rvu’ing  the  1 0'.i. 
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A.  Line  InUrfaoe 

Input  Data  Une  (Input) 

The  input  from  the  subacriher  may  be  either  two-wire  balanced  or  unbalanced  lines.  The  lines  may 
contain  some  modulaU>d  signal  which  must  be  demodulated  to  NRZ  or  they  may  contain  NRZ  signals. 
Such  modulated  signals  as  conditioned  di-phase  and  others  allow  the  line  interface  module  to  derive 
clock;  whereas,  an  NRZ  signal  must  be  accompanied  by  a clock  input  since  clock  cannot  be  derived 
from  it.  The  signal  is  taken  off  the  line  via  an  appropriate  signal  receiver. 

Output  Data  Line  (Output ) 

The  output  to  the  subscriber,  like  the  input  from  the  subscrilier.  may  be  NRZ  or  a modulated  signal. 

If  the  line  contains  synchronous  data,  the  line  interface  may  generate  a sync  pattern  or  character  as 
required  by  the  subscriber.  The  signal  is  applied  to  the  line  via  the  line  driver. 


Timing  In  (Input) 

Message  Switch  line  handler  timing  is  supplied  by  the  line  device  via  this  line  in  the  event  that  NRZ 
signals  or  other  signals  are  on  the  input  lines  that  cannot  be  used  fur  clock  recovery.  This  assumes 
that  the  line  device  supplies  master  timing. 

Timing  Ow  (Output) 

If  the  subscriber  derives  its  clock  from  the  Message  Switch  and  the  subscriber  cannot  derive  the  clock 
from  the  type  signal  on  the  output  line,  this  line  is  used  by  the  Message  Switch  to  supply  the  timing. 


B.  Processor  Interface 

Data  Bus  (Input/Output) 

This  bus  is  an  8-bit,  parallel,  bidirectional  bus  used  for  transfer  of  data  to  and  from  the  line  handler 
processor.  When  data  is  to  be  passed  to  the  processor,  the  data  is  held  in  an  8-bit  data  renter  until 
the  processor  acci-pts  the  vectored  interrupt  from  the  line  interface  unit.  The  processor  then 
addresses  the  line  interface  unit  and  "Fetches”  the  character,  using  the  I/O  Read  line. 

Address  Bus  ( Input/Output ) 

This  u a 16-bit  bus  which  is  used  by  the  line  handler  processor  to  address  the  various  line  interface 
modules  and  the  memory  locations.  Only  5-bits  of  this  bus  are  required  for  line  interface  modules 
since  the  number  of  these  modules  will  probably  never  exceed  32  for  a single  line  handler.  In  ord’^r 
for  a line  interface  module  to  pass  or  receive  data  to  or  from  the  processors,  it  must  recognize  its 
address  on  the  address  bus. 

1/OJtead  (Input) 

This  line  is  supplied  to  the  line  interface  module,  along  with  the  address,  h,  the  line  handler  processor 
to  load  the  data  word  from  the  data  bus  into  the  module. 


I/O  Write  (Input) 

This  line  is  supplied  to  the  line  interface  mmlule,  along  with  the  address,  by  th«-  line  handler  processor 
to  load  the  data  wrord  from  the  data  bus  into  the  module. 

Input  Word  Ready  (Output) 

This  line  serves  as  the  interrupt  to  the  Line  Handler  Processor,  informing  it  that  a character  has  b<‘en 
received,  and  is  ready  to  be  fetched  and  processed.  The  address  bus  will  contain  the  address  of  that 
Line  Interface  to  Input  Service  Module  interrupt  routine. 

Next  Word  (Output) 

This  is  an  interrupt  to  the  Line  Handler  Processor,  addressing  the  line  interface  to  Output  Service 
Module  interrupt  routine.  'I’his  routine  will  either  output  another  character  or  set  an  output  status 
flag,  and  reset  the  interrupt. 

Loss  of  Bit  Sync  (Output ) 

This  lint  is  a status  report  to  the  line  handler  that  bit  synchronization  has  been  lost.  WTiat  is  done 
about  the  report  is  a system  definition. 

Clock  Input  (Input) 

This  line  contains  the  line  handler  clock  and  is  used  by  the  synchronization  circuits  to  generate  clock. 

//.  Inputs 

A.  Input  Data  Lines 

1,  Format: 

a.  Transmission  Inputs 

Signal  may  be  conditioned-diphase  or  NRZ  serial.  Code  may  be  7-bit  .ASCII  or  5-bit 
Baudot  asynchronous  with  a start  bit.  a parity  bit.  and  1 or  2 stop  bits.  Code  may  also 
be  7-bit  ASCII  synchronous  and  1 bit  of  parity. 

b.  Processor  Input 

5-bit  Baudot  or  7-bit  .ASCII  characters. 

2.  Input  Ports; 

The  Une  Interface  .Module  is  a bilateral  device.  It  ivceives  data  from  the  transmission  lines  and 
also  from  the  processor  data  bus. 

a.  Transmission  Line  Input  Port 

This  input  port  is  a receiver  that  is  designed  for  detecting  the  type  signal  on  the  line;  i.e. 
MIL-STD-188C'.  MIL  STD- 188- 100.  etc. 

b.  Processor  Data  Bus 

This  input  is  an  8-bit  parallel  bus  (bidirectional). 


3.  Multiplex  Requirements; 

None. 

4.  Timinfi  (Rate); 

a.  Tran.smission  Line  Input  Port 

Inputs  vary  from  45.5  bits/sec  Baudot  a.synchronous  to  16,000  bits/sec  ASCII  synchronous. 

b.  Processor  Data  Bus 

Inputs  are  8 parallel  data  lines.  16  paralleled  address  lines  and  6 parallel  control  lines. 

5.  Timing  I Sequence): 

a.  Transmission  Line  Input  Po’-t 

Character  bits  are  input  as  they  are  detected,  in  the  asynchronous  system.  In  the  .synchron- 
ous system,  characters  are  received  in  time  with  the  generated  clock. 

b.  Processor  Data  Input 

Characters  are  input  in  time  with  address  and  control  lines.  a.synchronou.sly 

6.  Addressing: 

a.  Transmission  Line  Input  Port 
No  addressing 

b.  Processor  Data  Input  Port 

One  address  per  character  received. 

B.  Input  Control  Lines 

1,  Format: 

a.  Timing  In 

This  is  a standard  square  wave  pulse  chain  running  at  the  rate  of  the  data  being  rM'eivpd 
ranging  from  45.5  pulses/sec  to  16  K pulses  s«>c.  l.'sed  only  when  data  is  N'RZ. 

b.  Clock  Input 

This  is  a standard  square  wave  pulse  chain  running  at  some  muiti|>le  of  the  data  being 
received  on  the  Transmission  Line  Input. 

c.  I 'O  Read/I/O  Write  Inputs 

The  lines  are  levels  only  and  are  a<'tivated  by  th«*  prin  esMir  when  the  Line  Interface 
Module  is  to  read  or  write,  respectively. 

2.  Input  Ports; 

a.  Timing  In 

A receiver  designed  to  det«'t  the  signal  on  the  line;  i.e.,,  .MIL-STD-188C.  .MIL  STD-1 88  100. 
etc. 

b.  Gock  Input 

A standard  pin  in. 
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c I 'O  Read  I 'O  Write  Inputs 

Standard  pm  ms.  a part  of  th<*  proeessor  <-onlrol  bus 

G Multiplex  Re<iuirement.s 
None 

4 Timing  1 Rate  I 
a iimmg!!'i 

This  input  only  «*xists  if  NRZ  is  being  received  on  the  Transmission  Line  Input 
(.Sii*  para  I!  B l.ai 
t.  (’io(  k Input 

(Se«‘  para.  H.B  l.bi 
c 1 O Read  I O t\rite 

A.syn<  hronous  (.Se<>  para  lI.B.l.c  i 

5.  Timing  I Sequence); 
a Timing  Ir. 

(See  para.  II.B.l.a) 
b Clock  Input 

(See  para.  U.B.l.b,* 
c.  I'O  Read/I  'O  Write 
(See  1- . 1.  Il.B.l.c) 

6.  Addressing 
Not  applicable 

///.  Outputs 

A.  Output  Data  Lines 
1,  Format: 

a.  Tran-smission  Outputs 

Conditioned  diphase  or  NRZ  vrial  dat  i Code  either  .'i-liij  cr  7 fiit  .\s{  !| 

a.synchrunous.  or  7-bit  ASCII  ..snehronous  with  appn  priate  •Imj.  .md  par;!>  b 

b.  Processor  Outputs 

5*hit  Baudot  or  7-bit  ASCII 


2.  Output  Ports: 

a.  Transmission  Output  Ports 

An  appropriate  driver  for  producing  required  waveform  on  line;  i.e..  MIL-STD-188C 
driver.  MIL-STD-188-100  driver. 

b.  Processor  Output  Ports 

8-bit  Parallel  bus  (bidirectional) 

3.  Multiplex  Requirements: 

None. 

4.  Timing  (Rate): 

a.  Transmission  Output 
(See  para.  II.A.4.a) 

b.  Processor  Output 
(See  para.  lI.A.4.b) 

5.  Timing  (Sequence): 

a.  Transmission  Output 

Character  bits  are  output  at  the  required  line  data  rate  varying  from  45.5  bits/sec  to  16  K 
bits/sec. 

b.  Processor  Data  Output 

Characters  are  output  in  time  with  address  and  control  lines,  asynchronously. 

6.  Addressing: 

a.  Transmission  Output 
Not  applicable. 

b.  Processor  Data  Output 

One  address  per  character  output. 

B.  Output  Control  Lines 
1.,  Format: 

a.  Timing  Out 

This  output  exists  only  if  the  message  switch  is  the  master  ti.ne  source.  It  is  a symmetrical 
square  wave  pulse  chain  running  at  a rate  depending  on  the  data  rate  of  the  transmission  line 
and  varies  from  45.5  pulses/sec  to  16  K pulses/sec. 

b.  Loss  of  Bit  Sync 

This  output  is  a DC  level. 

c.  Input  Word  Ready 

This  output  is  a DC  level. 

d.  Ready  for  Next  Word 
This  output  is  a DC  level. 


2.  Output  Port 

a.  Timing  Out 

An  appropriate  driver  for  producing  required  waveform  on  line;  i.e.,  MIL-STD-188C, 
MIL-STD-188-100,  etc. 

b.  Loss  of  Bit  Sync 

Standard  pin  out  to  processor. 

c.  Input  Word  Ready 
Standard  pin  out  to  processor. 

d.  Ready  for  Next  Word 
Standard  pin  out  to  processor. 

3.  Multiplex  Requirements: 

None. 


4.  Timing  (Rate): 

a.  Timing  Out 

(See  para.  III.B.l.a) 

b.  Loss  of  Bit  Sync 

Raised  when  bit  sync  is  lost.  Raised  in  sync  with  Clock  Input  signal. 

c.  Input  Word  Ready 

Raised  when  Line  Interface  Module  has  word  to  send  to  processor.  Asynchronous. 

d.  Ready  for  Next  Word 

Raised  when  Line  Interface  Module  is  ready  for  another  word  to  put  on  the  transmission 
line.  Asynchronous. 


5.  Addressing: 
None. 


IV.  Transfer  Chancteristics 
A.  Transmission  Input  Data  to  Processor  Data  Bus 
1.  Hrroughput  Delay  (Data  Rate  ® 16  kb/s). 

Time  to  receive  8-bit  serial  character  at  16  K B/S  is  500  ^sec.  This  is  a function  of  the  data  rate. 
Time  to  convert  from  serial  to  parallel  is  62.6  fisec.  This  is  assuming  internal  clock  running  at 
data  rate,  16  KB 

Time  to  transfer  character  from  Line  Interface  Module  to  Input  Service  function  is  10  ^$ec. 
Total  throu^put  delay  per  character  Is  672.5  usee. 


J-ll 


-y 


B.  Processor  Data  Bus  to  Transmission  Output 
1.  Throughput  Delay  (Data  Rate  = 16  kb/s). 

Time  to  receive  8-bit  character  (parallel)  from  Input  service  function  is  approximately  10  psec. 
Time  to  convert  from  parallel  to  serial  and  transmit  out  at  16  K B/S  is  approximately  562.5  /isec. 
Total  throu^put  delay  per  character  is  572.5  psec. 

SWITCHING  FUNCTION  MODULE:  INPUT  SERVICE  MODULE,  TYPE:  PRIMARY 

1 

/ General 

The  Input  Service  Module  is  a software  module,  resident  in  the  Line  Handler  Processor,  that  directs  the 
checking  of  receive  protocol,  the  translating  of  codes,  the  checking  of  parity,  and  the  rebiocking  of 
messages.  It  also  passes  the  message  blocks  to  common  memory  for  further  processing  and  routing.  The 
module  is  called  by  the  Line  Interface  to  Input  Service  Module  interrupt  routine.  This  module  is  one  of 
several  that  is  implemented  within  a Line  Handler  Procer>sor. 

A.  Subscriber  Protocol 

The  Input  Service  Module  performs  all  protocol  checks  on  messages  received  by  the  switch.  After  the 
message  has  been  demodulated  to  NRZ  and  formatted  into  8-bit  bytes  by  the  Line  Interface  Module, 
it  is  “fetched”  by  the  Line  Handler  Processor,  under  direction  of  the  Input  Service  Module,  and 
checked  for  its  protocol  legitimacy;  i.e.,  SOM,  STX,  EOM,  etc.  If  protocol  is  conect,  the  parity  of 
each  message  byte  is  checked  and  if  block  parity  check  is  required,  it  is  performed  at  the  end  of  the 
message  block.  If  the  message  is  being  received  from  an  ASCII  type  subscriber,  it  is  stored  byte-by-byte 
into  the  Line  Handler  local  storage  for  further  processing. 

B.  Code  Translation 

If  the  mcrssage  is  being  received  from  a subscriber  that  uses  Baudot  code,  it  must  be  translated  to 
ASCII,  which  is  the  code  used  by  the  switch.  The  bytes  are  translated  by  the  code  translation  routine 
and  {rfaced  into  local  memory  for  further  processing. 

Mwsage  Reformatting 

If  relocation  of  bytes  within  the  message  header  are  required,  the  Input  Service  Module  controls  the 
Line  Handler  Processor  in  performing  this  task.  Also,  if  messages  are  segmented  for  transmission,  this 
module  performs  this  task,  adding  the  date/time  group  and  the  originator  routing  indicator  to  the 
header,  as  required. 

D.  Message  Transfer 

The  Input  Service  Module  controls  the  Line  Handler  Processor  in  transferring  the  message  to  common 
memory  for  further  processing  and  routing  by  the  central  processor.  The  Line  Handler  Processor, 
under  control  of  the  Input  Service  Module,  reads  from  a “mail  box”  in  common  memory  the  address 
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at  which  the  message  from  the  Line  Handler  should  begin.  The  Line  Handler  transfer  the  message, 
one  character  at  a time  to  common  memory  in  segments  made  up  of  multiple  bytes.  The  segments 
are  chained  in  common  memory  by  the  Line  Handler  to  form  the  complete  message. 

//.  Inputs 

A.  Format:  Character  oriented  messages;  each  character  is  7-bit  ASCII  with  1 parity  lut,  or  Baudot  with 
parity  bit. 

B.  Input  Ports:  (1)  8-bit  parallel  data;  (2)  16-lnt  parallel  address;  (3)  4-bit  parallel  control  lines; 

(4)  “fetch”  from  Line  Interface  Module. 

C.  Multiplex  Requirements:  None.  The  system  bus  is  dedicated  to  this  task  until  complete. 

D.  Timing  (Rate):  The  Uming  varies  wi^  appiicaUon.  It  will  vary  from  a low  of  6.7  char/sec  asyn- 
chronous Baudot  to  a high  of  1200  char/sec  synchronous  ASCII.  All  transfers  are  one  character  at 
a time. 

1.  Asynchronoiu  Baudot.  Since  all  transfers  occur  on  a 8-bit  byte  basis,  a Baudot  character, 
which  is  six-bits  long  (including  parity)  is  transferred  with  two  ignored  bits.  Because  “letter 
shift”  and  “number  shift”  characters  are  required  to  obtain  the  complete  character  set  in 
Baudot,  it  is  assumed  that  for  every  11  Baudot  characters  received  10  ASCII  characters  are 
output. 

2.  Synchronous  ASCII.  Since  no  translation  occurs  the  output  equals  the  input. 

3.  Measage  Content.  A date/time  group  is  added  to  the  header  before  characters  are  output,  thus 
the  ou^Mit  message  contains  more  characters  than  the  input  meisage.  Assume  8 characters 
added  for  every  160  characters;  i.e.,  for  160  chars-in  there  are  168  chars-out  (1:1.05  ratio). 

E.  Timing  (Sequence):  Transfer  of  data  k performed  on  data  lines  under  control  of  the  processor 
control  lines,  asynchronously. 

F.  Addressing:  Two  addresses  per  character  transferred  are  required  - one  for  “fetching”  from  Line 
Interface  Module  buffer  and  one  for  loading  to  local  memmry. 

III.  Outputs 

A.  Fovnuk:  Character  oriented  roessagss;  8-bit  ASCII  characters. 

B.  Output  Port:  8-bit  parallel  data,  16-bit  paralld  address,  4-bit  parallel  control  lines;  load  to  common 
mMiory. 

C.  Multiplex  Requirements:  None. 

D.  Timing  (rate):  See  Inputs. 


J-13 


I. 


▼ 


E.  Timing  (sequence):  See  Inputs. 

F.  Addressing:  Two  addresses  per  character  transferred  are  required  - one  for  “fetching”  tfie  character 
from  the  local  memory  and  the  other  for  loading  the  character  to  common  memory. 

G.  Other  Outputs:  Defined  under  Output  Port. 

IV.  Transfer  Chanctertsrtcs 

A.  Throu^put  Delay.  Each  input  word  produces  an  equivalent  output  word.  Delay  between  input 
word  and  output  word  as  a result  of  storage  of  message,  translation  of  codes  (if  required),  reformat- 
ting of  heador,  and  loading  to  Common  Memory  is  approximately  2 ms  per  character.* 

SWITCHING  FUNCTION  MODULE:  OUTPUT  SERVICE  MODULE,  TYPE:  PRIMARY 

/.  General 

The  Ou4>ut  Service  Module,  a software  subroutine  resident  in  the  Line  Handler  Processor,  polls  the  mail- 
boxes in  the  common  memory,  adikh  contain  pointers  to  output  messages  which  are  to  go  to  subscribers 
via  the  Line  Interfiace  Module.  This  module  also  controls  the  output  protocol  with  the  subscriber,  and 
translates  the  message  into  Baudot,  if  necessary.  Output  Service  also  controls  Uie  building  of  message 
headers,  and  the  reblocking  of  messages,  as  required. 

A.  Memory  TVansfer 

The  Output  Service  Module  causes  the  Line  Handler  Processor  to  poll  specified  locations  in  common 
memory  to  determine  if  messages  have  been  queued  for  any  of  ttie  subscribers  being  serviced  by  this 
particular  Line  Handler.  When  a message  is  ready,  it  is  transferred  by  the  jwocessor,  byte-for-byte,  to 
the  Line  Handler  local  storage,  going  through  Code  Translation,  if  necessary. 


B.  Code  Translation 

If  the  message  is  being  sent  to  a subscriber  that  uses  a different  code  than  the  message  switch,  die 
t^tes  are  translated  by  the  code  translation  routine  and  placed  back  in  local  memory  for  fiirther 
processing.  This  selection  is  fixed  at  design  time. 


C.  Message  Reformatting 

If  the  subscriber  requires  a unique  type  header  for  the  message,  that  header  is  constructed  by  this 
routine.  Bee  Basic  Message  Layout  (Figure  F-2)  for  details  on  the  header. 

D.  Output  Protocol 

The  Ou^t  Service  Module  controls  the  Line  Handler  Processor  in  (^orating  the  propor  protect 
for  the  subscriber;  i.e.,  SOM,  STX,  EOM,  etc.  This  module  also  controls  the  transfer  of  the  messj^^e 


*The  ULMS  application  is  characterised  by  a maximum  arrival  rate  of  1 char/3.5  ms. 
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bytes  into  the  line  Interface  Module  for  transmission.  The  module  recognizes  ACK  or  NAK  from 
the  subscriber  and  resends  a message,  if  required,  after  the  receipt  of  a NAK.  The  module  also  adds 
character  parity  and  block  parity,  if  required  by  the  subscriber. 


//.  Inputs 

A.  Fmrmat:  Character  oriented  messages;  8*bit  ASCII  characters. 

B.  Input  Port:  8-bit  parallel  data;  16-bit  parallel  address,  4-bit  parallel  control  lines;  “fetch”  from 
common  memory. 

C.  Multiplex  Requiranents:  None. 

D.  Timing  (Rate):  Timing  varka  with  application.  will  vary  hrom  a low  of  5.7  char/sec  asynchronous 
to  a hi^  of  12(X)  char/sec.  In  a message  processing  mode,  the  Output  Service  Module  transfers  80 
characters  per  transaction  (a  block);  in  a scanning  mode,  the  Ou4>ut  Service  Module  transfers  two 
characters  per  transaction  (mailbox  contents).  All  transfers  from  common  memory  to  Line  Handler 
Stonge  an  one  character  at  a time,  asynchronous.  If  the  diameters  are  translated  to  Baudot  additional 
characters  will  be  added  to  account  for  diift  up  (alpha  characters)  and  shift  down  (numeric  characters). 
Assume  an  average  of  an  additional  shift  up  or  shift  down  character  for  every  ten  characters  of  text. 
Thenfmre  for  each  10  characters  in,  11  diameters  are  output. 

E.  Timing  (Sequence):  Tlransf«r  of  data  is  performed  asyndironously  upon  command  of  the  processor 
via  control  lines. 

F.  Addresdng:  Two  addresses  per  character  transferred  are  required  - one  for  “fetching”  from  common 
memory  and  one  for  loading  to  local  memory. 

ill  Outputs 

A.  Format:  Character  oriented  messagm;  each  character  is  7-Ut  ASCII  with  1-bit  parity  or  baudot  with 
parity. 

B.  Output  Port:  S-Mt  parallel  data,  16-bit  pamllei  address,  4-Ut  parallel  control  lines;  load  to  Line 
Interface  Module. 

C.  Multiplex  Requirem«its:  None. 

D.  Timing  Rate:  See  Inputs. 

E.  Timing  Sequemw:  See  Inputs. 
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F.  Addressing:  Two  addresses  per  character  transfer  • one  address  for  “fetching  “ from  local  memory, 
one  address  for  loading  to  Line  Interface  Module. 


G.  Other  Outputs:  Defined  under  Output  Port. 


IV.  Tnmtfer  Charmcteristks 

Throu^put  Oday:  Each  input  word  produces  an  equivalent  output  word  with  an  additional  output  word 
approximately  every  10  input  w<xds.  Delay  through  the  module  as  a result  of  fetching  each  character  from 
common  memory,  translating  it,  reformatting  the  header,  placing  it  in  local  storage,  and  then  transferring 
it  to  the  Line  Interface  Module  is  approximately  2.5  ms.'*  However,  the  character  will  be  held  in  local 
storage  (RAM)  until  requested  by  Line  Interface  Module. 


SWITCHING  FUNCTION  MODULE:  MESSAGE  JOURNALING  MODULE,  TYPE:  PRIMARY 


/.  Gmend  DeteripthH 

This  module  maintains  historical  records  of  all  traffic  which  has  been  processed  by  the  switch.  These 
records  are  designed  for  long-term  or  permanent  retention  and  infrequent  recall.  The  Message  Journaling 
Module  is  logically  and  electrically  independent  of  the  Message  Storage  Module. 


Normally,  all  processed  messages  in  the  switch  will  be  reflected  in  an  entry  in  the  Message  Journaling 
Module.  As  a minimum,  this  entry  will  include: 


A.  Path  Fidd  (indication  of  message  routing  prior  to  arrival  at  switch); 

B.  Header  (including  Precedence,  Classification,  Sender  and  Addressee  Routing  Indicators,  Message  Type, 
and  Message  Text  Code  and  Format): 

C.  Date/Time  of  Message  receipt;  and 

D.  Dete/Time  and  manner  of  disposition  of  each  message  copy. 


A noD-perishabte  message  may  be  preserved  in  its  entirety,  rather  than  simply  having  its  header  recorded. 
Items  (A)  through  (C)  above  may  be  received  from  the  Message  Storage  Module  prior  to  processing  by  the 
Validation  and  Routing  Modules,  and  Item  (D)  firom  the  System  Control  Module  after  final  disposition. 


//.  /agwft 

A.  Format:  Qiaractw  Strings  (messages  or  message  headers),  7-Ut  ASCII  with  one  parity  bit  per  charac- 
ter; strbig  iengtii  25-2(X>  chmacters  (message  headers)  or  500-8000  characters  (mmsi^s). 


B.  Input  Pmt:  DMA. 


*The  maximum  rate  out  for  the  ^tplication  selected  (ULMS)  is  4.5  ms  per  character. 


C.  Multiplex  Requirements:  None. 


D.  Timing  (rate):  Must  be  aUe  to  accept  characters  at  a rate  fast  enotiq^  to  store  ^e  data  listed  in 
section  I,  plus  the  current  processing  status  (requires  three  inputs  per  message),  without  building 
up  a queue. 

E.  Timbig  (sequence):  Address  and  enable  signds  raquired  no  later  than  data  characters;  if  internal 
address  tran^tion  is  done  for  each  addrera  (e.g.,  on  disk)  then  address  signal  required  same  period 
prior  to  data  character;  actual  timing  depends  on  compon«it/subsystem  choices. 

F.  Addressing:  (Hre  address  per  data  character;  address  length  dependent  on  journal  size  and  mapping 
tediniqptes  used. 

///.  Outpua 

A.  Format:  Same  as  Itqntt. 

B.  Output  Port:  DMA. 

C.  Multiplex  Requirements:  None. 

O.  Timinf  (rate):  Output  only  on  manual  command;  10  or  more  input  words  per  output  word. 

E.  Timing  (sequence):  Same  as  Input. 

F.  Addressing:  Same  as  Input 

IV.  1)witferCkMweteri$tk$ 

A.  The  Massage  Journaling  Module  will  store  Uie  informatiem  need  for  Mch  message  (see  Section  I)  but 
will  normally  only  output  when  a message  is  not  delivered. 

SWm»ING  FUNCnON  MODULE:  VALIDATION  MODULE,  TYPE:  PRIMARY 

/.  Geimtl  Dmrtptkm 

Message  validation  fiinctions  divide  easily  into  two  general  categories: 

A.  Format  VaUdation:  Insuring  that  incoming  messages  contain  a certain  minimum  amount  of  informa* 
tion,  and  contain  it  in  certahi  locations  in  the  message.  Example:  An  incoming  message  must  con- 
tain a SOM  (8t«rt  of  Measags)  serpience,  a 8TX  (Start  of  Text)  or  EOH  (End  of  Header)  sequence, 
and  an  BOM  (End  of  Message)  sequence.*  Thh  delimits  and  segregates  a message  from  the  balance 
of  a (potentiMiy  continuous)  input  bit  stream.  Format  validatimt  is  performed  by  the  Input 
Sarvice/Codc  ThmslMion  MotfcUe. 


*Depen^ig  on  the  message  formats,  there  may  be  a minimum  and  maximum  number  of  message  charac- 
ters behiMn  aOU  and  8TX/EOH,  and  between  STX/EOH  and  EOM. 
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Content  Validation:  Insuring  that  the;  contents  of  the  message  headers  are  such  that  delivery  of  the 
message  is  allowed  under  network  rules.  For  example: 

• Precedence  • is  the  originator  authorized  to  transmit  messages  with  the  stated  precedence? 

• Clas.sification  - is  the  originator  authorized  to  transmit  messages  with  the  stated  security 
classification?  Ai*.  the  addresses  authorized  to  receive  messages  with  the  stated  security 
c!a.ssification? 

• Message  Type  - does  the  me.ssage  type  indicator  correspond  to  an  allowable  me.ssage  type 
( perishable /nonperishable )? 

• Message  Text  Code  and  Format  • do  these  indicators  correspond  to  allowable  text  codes  and 
formats? 

• Addresses  - do  the  originator  and  destination  routing  indicators  iaddre.sscs)  refer  to  valid  sub- 
scriber locations  within  the  network? 

This  content  validation  implicitly  validates  the  internal  format  of  the  header  (by  assuming  that 
precedence,  classification,  and  other  indicators  are  located  at  specific  points  within  the  header). 
Content  validation  is  performed  by  the  ^^alidation  Module  in  the  CPU. 


The  Validation  Module  receives  message  headers  from  the  Message  Storage  Module  for  processing.  It 
retrieves  line  table  entries  from  the  Mes.sage  Storage  Module  or  elsewhere  to  do  character  comparisons 
as  a part  of  its  processing.  If  a message  is  found  invalid,  it  notifies  (passes  an  output  port  designator) 
the  Routing  Module  for  return  of  the  message  to  the  originator,  and  appends  a notation  to  the 
message  in  the  Message  Storage  Module  relating  to  the  reason  for  message  rejection;  in  some  cases  it 
may  notify  the  Routing  Module  for  output  to  the  Traffic  Service  Position  (TSP).  If  a message  is  found 
valid,  the  Validation  Module  notifies  the  Routing  Module  for  transmission  to  each  valid  addressee. 


The  Validation  Module  processes  messages  in  order  of  their  Date/Time  of  receipt,  within  each  prece- 
dence category.  It  scans  a section  of  ^obal  memory  (“mailboxes”)  reserved  for  intermodule  commu- 
nications, finding  pointin  to  messages  requiring  processing.  Scanning  each  message  header  in  turn, 
it  extracts  for  processing  that  header  with  the  earliest  Date/Time  Group,  within  the  highest  precedence 
category. 


//.  Input 

A.  Format:  16  bit  address  that  will  point  to  a list  of  par^imeters. 

B.  Input  Port:  8-bit  parallel  data;  16-bit  parallel  address.  4-bit  parallel  control  lines:  “fetch”  from  common 
memory. 

C.  Multiplex  Requirements:  None. 

D.  Timing  (Rate):  Timing  varies  with  application.  It  will  var\’ from  a low  of  5.7  char  sec  asynchronous 
to  a high  of  1200  char/sec.  In  a message  processing  mode,  the  Validation  .Module  transfers  30  charac- 
ters per  transaction  (a  message  header);  in  a scanning  mode,  the  Validation  Module  tr.-.nsfers  12  charac- 
ters per  scan  (mailbox  contents).  All  transfers  from  common  memory  are  one  character  at  a time, 
asynchronous. 


E.  Timing  (Sequence):  Transfer  of  data  is  performed  asynchronously  upon  command  of  the  processor 
via  control  lines. 

! F.  Addressing:  Two  addresses  per  character  transferred  are  required  - one  for  “fetching”  from  common 
memory  and  one  for  loading  to  local  memory. 

i til.  Output 

* 

A.  Format:  16  bit  return  code  and  parameter  list  addresses 

B.  Output  Port:  8-bit  parallel  data,  16-bit  parallel  address.  4-bit  parallel  control  lines;  load  to  Line 
Interface  Module. 


C.  Multiplex  Requirements:  None. 

D.  Timing  Rate:  Same  rate  as  Input.  In  a message  processing  mode,  the  Validation  Module  has  two 
characters  per  transaction  (mailbox  status)  output  to  common  memory;  in  a scanning  mode,  the 
Validation  Module  has  no  output  to  common  memory. 

E.  Timing  Sequence:  See  Inputs. 

F.  Addressing:  Two  addresses  per  character  transfer  • one  address  for  “fetching”  from  local  memory, 
one  address  for  loading  to  common  memory'. 

G.  Other  Outputs:  None. 


IV.  Trmufer  Chunctertstics 

The  validation  module  locates  the  message  header  from  the  parameter  list.  Each  field  is  validated  as 
described  in  the  general  description.  If  the  header  contains  invalid  information,  the  validation  routine 
will  create  a message  to  be  routed  back  to  the  originator  indicating  the  cause  for  rejection  and  set  the 
return  code  to  some  positive  value.  If  the  header  passes  all  edits,  the  return  code  will  be  set  to  zero. 


SWITCHING  FUNCTION  MODULE:  ROUTING  MODULE.  TYPE;  PRIMARY 
/.  Gtnerti  Description 

This  module  receives  notification  from  the  Validation  Module  of  the  location  (in  the  Memory  Storage 
Module)  of  messages  requiring  output  service,  and  arranges  for  the  appropriate  Output  Service/Code  Trans- 
lation Module  to  acquire  each  message  for  processing. 


As  the  Validation  Module  retrieves  the  line  table  entry  for  each  destination  addressee,  it  retains  the  identi- 
fication of  the  output  port  and  Output  Service/Code  Translation  Module  appropriate  to  that  addressee. 
Upon  completion  of  message  validation,  the  Routing  Module  receives  the  following  data  from  the 
Validation  Module: 

A.  Message  location  in  the  Message  Storage  Module; 

B.  Appropriate  output  port  indicator(s)  and  Output  Service/Code  Translation  Module  indicator(s); 

C.  Message  Date/Time  Group;  and 

D.  Message  Precedence. 

The  Routing  Module  maintains  a queue  of  messages  awaiting  output  service  for  each  Output  Service/Code 
Translation  Module.  As  it  receives  the  above  data  for  each  validated  message,  the  Routing  Module  must 
adjust  queues  to  insure  that  each  queue  is  ordered  by  Date/Time  Group,  earliest  first,  within  each  prece- 
dence class  (highest  precedence  first).  Each  queue  entry  contains  a message  location  and  an  output  port 
indicator.  The  top  entry  in  each  queue  is  retained  in  a section  of  global  memory  (“mailboxes”)  reserved 
for  intermodule  communications.  It  is  scanned  periodically  by  the  appropriate  Output  Service  Code 
Translation  Module,  and  serves  as  a pointer  to  the  next  message  needing  output  service  in  that  module. 

The  Routing  Module  must  maintain  cognizance  of  the  output  actions  performed  on  each  message.  In 
particular,  it  roust  note  when  all  copies  of  a multiple-address  message  have  been  transmitted,  so  that  the 
Memory  Management  Module  can  be  notified  to  deallocate  the  buffer  space  in  the  Message  Storage  Module 
which  was  assigned  to  that  message.  The  Routing  Module  must  also  transmit  an  alarm  to  the  System 
Control  Module  in  the  event  of  queue  overflow  or  of  message  retention  in  a queue  for  a period  exceeding 
that  specifled  in  System  Speed  of  Service  (SOS)  requirements. 

//.  Input 

A.  Format:  16  bit  address  of  parameter  list. 

B.  Input  Port:  Microprocessor  register  (direct  from  Validation  .Module  i. 

C.  Multiplex  Requirements:  None. 

D.  Timing:  Virtually  no  time  involved  (common  register  with  Validation  Module). 

E.  Addressing:  Not  applicable. 

///.  Output 

A.  Format:  16  bit  return  code  w'urd  and  parameter  list  address. 

B.  Output  Port:  Microprocessor  registers. 

C.  .Multiplex  Requirements:  None. 

D.  Timing:  Timing  varies  with  application.  It  will  vary  from  a low  of  5.7  char  ser  asynchronous  to  a 
high  of  1200  char/sec.  Routing  Module  outputs  six  characters  per  transaction  i buffer  addresses  to 
common  memory). 

E.  Addressing:  Two  addresses  required  pei  character:  One  in  local  memoiy.  one  in  common  memorv-. 

F.  Other  Outputs:  None. 
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ly.  Transfer  Characteristics 

The  Routing  module  locates  the  destination  |)ort  addn>sses  from  the  parameter  list.  A specific  output  line 
number  is  found  for  each  .symbolic  destination.  Tbis  line  number  along  with  other  information,  is  placed 
in  the  Route  Control  Word  (RCW).  The  RCW*s  are  then  put  in  the  line  handler  queues  for  output 
scheduling.  (The  queue  addresses  having  been  provide<l  in  the  parameter  list.) 

SWITCHING  FUNCTION  MODULF;  MESSAGK  STORAGE  MODULK,  TYPF,:  .SECONDARY 

/.  Genend  Description 

After  a message  has  been  accepted  from  a loop  or  trunk,  and  has  experienced  code  translation  and  refor- 
nutting  as  necessary,  it  is  passed  to  the  Message  Storage  Module.  The  Message  Storage  Module  retains  the 
message  from  the  time  it  is  released  by  an  Input  Servicc/Code  Translation  Module  until  it  is  accepted  by  the 
appropriate  Output  Service/Code  Translation  Module  (or  in  the  case  of  multiple-addresses,  until  it  is 
accepted  by  all  the  appropriate  Output  Service/Code  Translation  Modules).  During  this  retention,  portions 
of  the  message  will  be  released  to  the  Validation  Module  and  the  Routing  Module  for  those  proces.ses. 

Also,  all  or  port  of  the  message  will  be  released  to  the  Message  Journaling  Module  for  historical  record- 
keeping. 

Depending  on  the  volatility  of  the  message  contents,  as  well  as  the  position  of  the  switch  in  the  switch 
‘ network*,  message  retention  may  be  estended  to  the  point  where  delivery  has  been  confirmed  to  the 

> destination  terminal  (even  if  it  it  a subscriber  to  a different  switch).  In  cases  where  the  message  cannot  be 

accepted  by  the  appropriate  Output  Service/  Code  Translation  Module,  all  or  a portion  of  the  mes-sage  will 
be  ddivered  to  the  Output  Service/Code  Translation  Module  appropriate  to  the  Traffic  Service 
Position  (TSP). 


As  a type  “Secondary”,  the  Message  Storage  Module  may  also  contain  some  or  ail  of  the  program  instruc- 
tions used  by  other  modules.  It  will  contain  tables  of  line-by-line  classmarks  and  statusmarks,  as  well  as 
routing  tables. 

It  is  estimated  that  4K  words  of  memory  will  be  sufficient  for  message  storage. 

i 

It.  Inputs 

A.  Format:  Character  stringi  (messages),  7-bit  ASCII  with  one  parity  bit  per  character;  average  string 
' lengri)  320  characters,  maximum  string  length  1280  characters,  in  block  of  80  characters. 

( [ 8.  Input  Port:  Interface  to  architecture. 

l| 


*For  example:  Whether  the  message  represents  loop-to-trunk,  trunk-to-trunk,  or  trunk-to-loop  traffic 
for  the  switch. 
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C.  Multiplex  Requirements:  None  implicit;  actual  implementation  requirements  depend  on 
architecture. 

D.  Timing  (rate):  Must  bo  able  to  accept  characters  and  storage  addre.sses  at  least  as  fast  as  architecture 
supplies  them;  actual  timing  depends  on  component  choices;  (average)  less  than  1 input  word  per 
output  word. 

E.  Timing  (sequence):  Address  and  input  enable  signals  required  no  later  data  signals;  simultaneous  or 
sequential  arrival  may  depend  on  architecture;  may  depend  on  component  choices. 


F.  Addressing;  One  address  required  per  data  character  input;  word  length  dejiendent  on  memor>’  size 
and  mapping  technique  used. 


///.  Outputs 

A.  Format;  Same  as  Input;  same  maximum  character  string  length;  average  character  string  length 
smaller  (200  characters)  since  bo^h  complete  messages  and  partial  messages  (headers,  etc  ) are  output. 

B.  Output  Port:  Same  as  Input  Port. 

C.  Multiplex  Requirements:  None  implicit;  all  or  portion  of  each  message  to  be  output  at  different 
times  for  diffctent  processing. 

D.  Timing  (rate):  Must  be  able  to  supply  characters  up  to  rate  at  which  architecture  accepts  them;  see 
Inputs. 

E.  Timing  (sequence):  Character  output  accomplished  after  receipt  of  address  and  output  enable 
signals;  timing  dependent  on  component  choices. 

F.  Addressing:  One  address  character  per  output  character. 

G.  Other  Outputs:  Dependent  on  architecture  and  implementation:  none  implicit. 

iV.  Tnmsfer  Chtncteristics 

A.  Throughput  Delay:  Total  of  original  storage  time,  recall  times  for  output  to  various  modules  for 
processing,  recall  time  for  output  to  appropriate  Output  Service, 'Code  Translation  Modules),  and 
recall  time  to  output  to  Oitput  Service/Code  Translation  Module  appropriate  to  TSP.  May  also 
include  wait  time  until  conFirmation  of  Hnal  delivery.  Because  the  processors  attached  to  the 
memory  are  slow  (5.5  laec  cycle  time)  a slow  memory'  is  satisfactory'. 


B.  Scaling;  1.1  to  2.5  (approx.)  output  word.s  pi>r  input  word. 

C.  Fault  Detection:  Error  detection  and  corrwtion  (EDAC)  may  be  add(>d.  and  lx*  transparent  to  the 
rest  of  the  system,  by  adding  the  projx'riy  c oded  bits  to  each  word  of  data. 

GKNERAIJZFJ)  SFX:OM).\RY  FlJ.MCTION.‘< 

/.  tnitialization 

All  of  the  actions  nect>ssary  to  begin  processing  mes.sages  are  included  in  the  initialization  function.  The 
initialization  tasks  can  vary  greatly  between  different  switch  implementations.  These*  tasks  may  be  nandled 
either  manually  by  the  operator  or  automatically  under  software  and.'or  hardware  c.introl.  The  number  of 
tasks  performed  will  generally  increase  as  the  amount  of  switch  flexibility  grows.  Foi  a very  rigid  system 
initialization  may  be  simply  applying  power  to  the  switch.  In  the  more  general  case,  however,  initialization 
would  involve  performing  specific  actions  needed  to  set-up  each  of  the  other  functions  nece.ssary  to  l.ie 
proper  functioning  of  the  switch.  For  example,  before  message  routing  can  operate  properly,  the  route 
tables  must  be  built  and  verified.  System  Control  must  lie  aware  of  all  the  input  and  output  ports  he  is 
controlling  and  of  their  current  status.  Buffer  space  must  be  provided  for  messages.  The  cunent  memory 
configuration  must  be  supplied  to  Memory  Management.  These  along  with  other  implementation  dependent 
tasks  prepare  the  switch  to  begin  processing  messages.  Once  ail  of  the  necessary  initialization  tasks  have 
been  performed,  processing  is  begun  by  System  Control. 

//.  SystfiH  Control 

The  means  by  which  the  other  functions  art*  at'compli.shed  is  the  function  of  .System  Control.  There  may 
be  a number  of  functions  performed  in  accomplishment  of  swiu-hing  a ine.ssage.  To  determine  the  orderly 
processing  of  these  functions  System  Control  must  mawilain  certain  hou.sekeeping  activities.  .An  accurate 
status  of  the  switch  and  an  exact  configuration  of  the  input/output  ports  must  Ixi  maintained.  Ihe  input/ 
output  queues  must  be  adjusted  to  handle  the  mfr,.sage  traffic  load.  The  results  of  these  housekeeping 
activities  allow  System  Control  to  determine  the  next  function  to  lx*  performed.  If  such  a determina  >n 
cannot  be  made,  control  will  be  passed  on  the  Error  Recovery  function. 

m Memory  Management 

All  memory  allocation  and  deallocation  is  the  function  of  .Memory  Management.  Requests  for  service  are 
generally  received  from  only  System  Control.  Thi*se  requests  arc  processed  successfully  or  are  rejected 
for  some  speciBed  reason.  A memory  reorganization  routine  is  usually  included  to  aid  in  more  efficient 
memory  usage.  Ihis  function  is  a simple  but  very  important  part  of  the  message  switch. 

/y.  Error! Recovery 

Error  detection  and  the  corresponding  corrective  actions  make  up  the  Error/  Rec  overy  function.  Error 
detection  is  initiated  whenever  System  Control  enci^unters  any  unanticipated  conditions.  These  conditions 
are  viewed  by  the  detection  routines  to  ascertain  what  error  has  occurred.  If  possible,  the  recovery 
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routinos  will  corrpot  the  situation  before  returning  control  to  the  system.  As  a result  of  corrective  actions 
taken,  the  system  may  continue  operating  at  full  capacity  or  at  some  degraded  .state.  If  continuation  is 
impossible,  the  alarm  system  is  used  to  signal  a request  for  manual  intervention.  In  most  implementations 
It  IS  hard  to  make  a clear  division  between  Hy.stem  ('onirol  and  Krror  Recovery. 

V.  Diagnostic!  lest 

The  auxiliary  function  used  to  examine  and  analyze  the  mes.sa^ge  switch  is  Diagnostic/Test.  This  function 
is  unique  from  other  switch  functions,  since  it  is  not  neces.sary  for  [iroper  operation.  It  is  included  to 
ensure  the  timely  correction  of  switc-h  malfunctions  by  helping  to  localize  the  problem  and  to  verify 
proper  switch  operation.  The  Test  function  is  used  on  a regular  basis  to  exercise  all  the  switch  functions 
and  ensure  they  are  functioning  properly.  The  diagnostics  function  is  available  to  aid  the  servicing  tech- 
nician to  locate  and  correct  faults  in  the  switch  after  an  alarm  has  been  activated  by  Error/Recovery. 
Typically  the  message  switching  functions  must  stop  while  Diagnostic/Te.st  is  being  utilized. 
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BRIEF  DESCRIPTION 


The  flowcharts  that  follow  are  a representation  of  the  general  signal  processing  and  switching  model 
studied  under  this  contract.  The  symbols  are  GFSS  blocks  that  relate  to  the  major  functions  of  the  model. 
The  flowcharts  arc  interconnected  by  off-page  connectors,  which  identify  the  figure  number  and  con- 
nector number. 

Figure  K.l  generates  the  specified  data  control  type  for  each  of  the  active  modules  in  the  system. 

Figures  K.2  and  K.3  show  the  logic  for  control  generation  for  decentralized  and  centralized  control 
respectively.  The  control  transactions  remain  dormant  until  the  specified  time  has  expired  whereupon 
the  input  and/or  output  routines  (figures  K.4  and  K.5)  are  activated. 

Figure  K.6  is  a block  diagram  of  the  input/output  routine  used  when  bus  transfer  is  accessed. 

Figure  K.7  is  a separate  routine  that  monitors  the  run  time  of  the  simulator  and  terminates  the  simula- 
tion run  when  time  has  expired.  It  additionally  tallies  all  the  statistics  accumulated  during  the  run. 
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LANGUAGE  SEI.ECTION 


I.  Bac'kf^round 

A.  Collins  Avionirs  Division  made  an  in-house  study  which  resulted  in  the  paper  titled  *‘A  Proposed 
Long  Range  HOL  Plan  for  Collins  Radio'*,  WP  3954  dated  March  17, 1976. 

The  applications  area  was  defined  as  avionics,  communi  -ation  switching  and  communication  products 
utilizing  imbedded  processors. 

Languages  studied  were  PL/1,  PL/M,  PL/M6800,  MPL,  PL-MIPROC,  FORTRAN,  BASIC, 

JOVIAL  J3B,  >^ED. 

ITie  lesulU  of  the  study  indicated  that  a subset  of  PL/I  would  be  most  effective. 

B.  Collins  Government  Telecommunications  Division  made  an  in-house  study  based  on  the  DoD  initiatives 
presented  at  an  AlAA  Conference  on  April  5—6, 1976, 

The  applications  area  was  defined  as  signal  processing,  message  handling  and  device  control  in  the 
secure  communications  field  for  equipments  utilizing  imbedded  processors. 

Languages  studied  were  CMS-2M,  Pascal,  Concurrent  Pascal,  Euclid,  PL-I,  AED,  CORAL  66, 
FORTRAN,  IFTRAN, 

The  context  for  this  study  was  the  DOD  Tinman  document  which  set  forth  a number  of  requirements 
and  desirable  features.  The  objective  was  to  anticipate  the  characteristics  of  the  language  which  would 
finally  result  from  DUD's  initiatives,  and  to  select  a similar  existing  language  for  near  term  .secure 
communications  applications. 

The  results  of  the  study  indicated  that  the  language  should  strongly  resemble  Pascal  with  extensions 
directed  toward: 

explicit  real  and  complex  arithmetic 
multi-tasking  and  resource  management. 

The  language  design  problems  involved  in  these  extensions  is  clearly  non-trivial  if  machine  dependencies 
are  to  be  avoided,  and  compiler  implementation  would  be  costly. 

The  conclusion  was  that  no  available  language  was  close  enough  to  the  mark  to  be  selected  for  use, 
and  that  the  selection  si  .^uld  be  delayed  until  the  results  of  ongoing  work  in  various  plai'es  could  be 
evalu.?.ted. 
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A side  result  of  the  study  was  the  recognition  that  the  requirements  of  formal  program  verificatjon 
techniques  should  have  a strung  influence  on  the  language  design,  particularly  in  the  applications  area 
of  secure  communications.  It  is  not  expected  that  these  techniques  will  be  widely  applied  in  industry 
for  a few  years,  but  they  will  then  probably  become  contractual  requirements. 

C.  At  the  beginning  of  the  present  study,  the  report  on  COL.  DCEC  fteport  R-3261  dated  .March  1 976 
was  brought  to  our  attention.  This  report  contains  a section  on  language  comparisons. 

The  applications  area  was  defined  as  communications  programming  and  systems  programming. 

Unguages  compared  were  FORTRA.N’  IV.  JOVIAL  J3.  PL/I,  C.  BCPL,  IMP.  E.SPL  l.  TPL2,  BLISS. 
Pascal. 

A conclusion  of  the  report  was  that  modifleation  of  an  existing  language  to  satisfy  DCA’s  requirements 
would  not  be  a cost  effective  alternative  to  development  of  a new  Communication  Oriented 
Language  (COL). 

ITie  design  of  COL  incorporates  the  worthwhile  features  of  Pascal  and  has  extensions  directed 
toward  multi-tasking  and  resource  management.  This  agrees  substantially  with  the  results  of  study  (B> 
above. 

2.  Briefly  Consideied 

Some  languages  were  considered  briefly  and  dropped  because  they; 

satisfied  too  few  of  the  criteria  given  in  section  3.3.5  of  the  main  report 
violated  too  many 

were  poor  prospects  for  rework  or  extension. 

In  this  category  were  PL/.M,  PL/.M6800,  .MPL.  JOVIAL.  PL-.MIPROC.  BCPL.  I.MP.  ESPL-1 . C.  TPL2. 

BLISS.  BASIC.  CMS-2.  COBOL,  EUCLID. 

3.  Seriously  Considered 

A.  Coral  66:  This  language  is  mandated  by  the  British  Ministry  of  Defense  and  a>>  such  was  of  special 
interest  in  this  applications  area.  The  language  specification  dated  .May  1970  show.<  it  to  contain 
many  of  the  needed  features.  However,  the  treatment  of  a Fortran-like  Common,  reliance  on 
implementation-dependent  operating  systems,  and  other  problems  imolving  escapes  to  machine 
code,  led  us  to  the  conclusion  that  although  it  overlapped  other  candidate>  such  as  PL  I and  SPL  I 
to  a large  degree,  there  were  disadvantages  without  signifii  ant  offsetting  advantages.  The  matter  of 
language  control  being  shared  between  two  Defense  establishments  also  brings  in  a new  set  of  pro  and 
con  arguments  which  are  believed  to  be  outside  the  scope  of  this  task. 
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B.  FORTRAN:  This  language,  particularly  in  its  structured  variants,  must  be  .seriously  considered 
l)ecause  of  its  unique  portability.  The  implementation  needed  for  portability  requires  a pre-processor 
which  turns  block  structured  symbolic  input  into  normal  compilable  Fortran  source  code.  Many 
u.sers  claim  ease  of  use  and  production  of  efficient  object  code.  However  nothing  more  can  actually 
be  done  that  cannot  he  done  in  Fortran  directly.  The  well  known  limitations  on  data  .structures; 
potential  for  problems  with  Common  constructs;  heavy  dependence  on  a run-time  machine-coded 
library  to  connect  with  machine  features  and  the  attendant  overhead'  all  these  considerations  lead 
to  the  conclusion  that  PL/1  should  be  considered  rather  than  Fortran. 

As  pointed  out  in  the  main  report,  however.  Fortran  will  probably  remain  an  important  factor  in  the 
generation  of  portable  compilers,  assemblers,  linkers  and  emulators. 

C.  Pascal:  This  language  has  received  a great  deal  of  attention  because  of  its  clean  design  and  ingenious 
data  structures,  strong  typing  and  the  like.  However  the  clean  design  is  partly  a consequence  of 
dismissing  certain  features  which  are  needed  in  this  application  area,  some  of  which  are  addressed  by 
Concurrent  Pascal. 

D.  Concurrent  Pascal:  The  sequential  language  Pascal  is  extended  to  include  programming  tools  called 
processes  and  monitors.  These  are  used  to  enable  efficient  operating  systems  to  be  wTitten  with 
multi-tasking  and  resource  control.  It  is  under  a continuous  state  of  development  in  the  academic 
and  commercial  fields  where  other  extensions  involving  arithmetic  have  also  been  installed.  As  finally 
extended  this  language  will  be  a strong  contender  for  serious  study.  Meanwhile,  for  the  purposes  of 
the  current  task,  this  language  will  be  considered  to  overlap  with  C'OL  to  the  extent  that  we  can  proceed 
as  if  COL  subsumes  it  in  principle.  That  is.  the  same  processes  and  monitors  can  be*  built  even  if  it  is 
necessary  to  use  the  Machine-Like-Code  feature  of  COL  to  do  it. 

4.  Selected  for  Comparison 

It  became  apparent  during  the  study  that  none  of  the  HOL's  being  reviewed  responded  fully  to  the  rntena 
developed.  The  notion  of  a •’composite-best"  language  was  considered,  .igainst  which  the  criteria  could  be 
tested  for  reasonableness  and  to  establish  the  size  of  the  gap  between  required  and  available  features.  .-\s 
this  would  have  required  generating  yet  another  language  definition,  something  the  world  already  has  plenty 
of,  it  was  decided  instead  to  select  about  three  of  the  leading  candidates  and  rate  them  against  the  criteria 
as  a collection. 

PL/I  was  selected  because  it  satisfied  most  of  the  criteria  with  one  outstanding  violation,  strong  type 
checking.  A consideration  which  is  not  on  the  list  of  cmena  but  is  nevertheless  very  significant  is  PL  I's 
wide  implementation  and  acceptance.  On  balance,  the  selection  of  PI*  I is  lielieved  to  be  justified, 
particularly  *f  we  allow  the  following  approach 

— for  this  applications  area,  we  can  easily  get  along  with  a proper  .subset  of  PL  1. 

— with  careful  subsetting,  a PL/I  compiler  can  be  implemented  which  will  produce  demonstrably  efficient 
object  code,  unlike  some  of  the  large  scale  general-purpose-prucessur  implementations. 
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SPL/I  was  selected  because  it  meets  most  of  the  criteria  and  in  addition  is  approved  for  use  under  DOD 
Instruction  5000.31. 

COL  was  selected  because  it  meets  most  of  the  criteria  and  has  the  best  treatment  of  Architecture  Oriented 
Code  (or  as  it  is  referred  to  in  the  COL  specification,  Machine-Uke-Code). 

Each  of  the  three  languages  has  most  of  the  features  which  are  to  be  expected  in  a current-day  language, 
in  which  detailed  comparisons  of  languages  tend  to  produce  “distinctions  without  a difference”.  These 
include: 

— Boolean  and  logical  data  types 

— Variations  of  DO  constructs 

— Variations  of  IF  constructs 

— Multibranch  conditionals,  with  satisfactory  CASE  constructions  for  SPL/I  and  COL  and  some  less 
tidy  equivalents  in  PL/I 

— Indexed  arrays 

— Other  data  structures  with  associated  pointers 

— Dynamic  storage  assignment/free  mechanism^ 

In  other  words,  although  the  above  features  differ  in  detail  and  power  it  is  difficult  to  find  examples  in  the 
application  area  being  studied  that  would  require  a change  to  the  language. 

In  Figure  3.3-6  of  the  main  report,  some  of  the  YES/MLC/NO  entries  in  the  table  require  further 
comment.  .See  Table  M-1. 
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COL 


SPL/I 


PL/J 


1 . HOL  Mechanisms  for 
(larallel  task  control 

TASKS 

EVENTS 

LOCK 

UNLOCK 

PRIORITY  OPTION 

REGION 

1 FLOCKED 

LOCK 

UNLOCK 

ELSE 

RETRY 

PROCE,SSES 

SIGNALS 

REQUEST 

RELEASE 

PRIORITY  ATTRIBUTE 

4.  Complex  arithmetic 

Real:  Real 

Note  1 

Integer:  Integer 
Fraction:  Fraction 
Real : Real 

5.  Character  handling 

CHARACTER 

Note  2 

STRING  (N) 

6.  Bit  manipulation 

BIT-string 

INTEGER  (BIT  3) 

BIT(N) 

7.  Precision  control 

Note  3 

i 

Note  3 

SINGLE 

DOUBLE 

10.  Type  checking 

• i 

1 Note  4 

Note  4 

YES 

NOTES 

1.  The  type  declarations  of  COL  allow  two  reals  to  be  paired,  but  this  begs  the  question  of  needing 
complex  arithmetic  syntax  of  the  kind  A:  = B * C D 


2.  The  type  CHAR  is  used  as  a pseudonym  fur  LOGICAL  data  of  a i>articular  (implementation- 
dependent)  size  and  is  for  programmer  convenience  only.  Tyiie-rhe-  ked  a.s  LOGICAL. 

3.  PL/I:  fixed  precision.  Cumbersome  for  fractions  because  of  left  truncation  on  multiply 

COL:  INTEGER  (A  N)  where  A .ignifies  BIT.  BYTE  or  WORD,  and  N = 1 . 2.  3 

4.  PL/1  is  the  reverse  of  strongly  typed,  to  put  u mildly,  liccause  of  built-in  conversions  that  may  ai'-o 
be  implementation  dependent  Puts  the  burden  on  the  (irogrammer. 

COL  is  strongly  typed  not  only  in  the  compiler  hut  the  proposed  linker  will  perform  typ«‘  checking 
when  linking  separavely  compikKi  modules. 
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The  following  bibliography  has  been  organized  in  four  sections:  ( A)  Architecture  and  ImpletnenUtion; 

(B)  Design  Methodology:  (C)  High  Order  i>anguages;  and  (D>  Standards.  Despite  this  attempt  at 
categorization,  overlap  does  exist  between  sections  (A)  and  (Bi.  and  topics  of  interest  in  the  general  area  of 
systems  design  propositions  will  be  found  in  both  sections. 
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